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Abstract 

Formal  software  specification  has  long  been  touted  as  a  way  to  increase  the  quality  and 
reliability  of  software;  however,  it  remains  an  intricate,  manually  intensive  activity.  An  alter¬ 
native  to  using  formal  specifications  is  to  use  graphically-based,  semi-formal  specifications  such 
as  those  used  in  many  object-oriented  specification  methodologies.  While  semi-formal  specifica¬ 
tions  are  generally  easier  to  develop  and  understand,  they  lack  the  rigor  and  precision  of  formal 
specification  techniques.  The  basic  premise  of  this  investigation  is  that  formal  software  specifi¬ 
cations  can  be  constructed  using  correctness  preserving  transformations  from  graphically-based 
object-oriented  representations.  In  this  investigation,  object-oriented  specifications  defined  using 
Rumbaugh’s  Object  Modeling  Technique  (OMT)  were  translated  into  algebraic  specifications.  To 
ensure  the  correct  translation  of  graphically-based  OMT  specifications  into  their  algebraic  counter¬ 
parts,  a  formal  semantics  for  interpreting  OMT  specifications  was  derived  and  an  algebraic  model  of 
object-orientation  was  developed.  This  model  defines  how  object-oriented  concepts  are  represented 
algebraically  using  an  object-oriented  algebraic  specification  language  0-Slang.  O-Slang  com¬ 
bines  basic  algebraic  specification  constructs  with  category  theory  operations  to  capture  internal 
object  class  structure  as  well  as  relationships  between  classes.  Next,  formal  transformations  from 
OMT  specifications  to  0-Slang  specifications  were  defined  and  the  feasibility  of  automating  these 
transformations  was  demonstrated  by  the  development  of  a  proof-of-concept  system. 
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Formal  Transformations  from  Graphically-Based  Object-Oriented  Representations 

to  Theory-Based  Specifications 


I.  Introduction 

1.1  Purpose 

The  insertion  of  traditional  engineering  methods  has  been  suggested  as  the  only  way  to  trans¬ 
form  software  development  from  an  art  into  an  engineering  discipline  (26,  8).  One  approach  to 
inserting  this  engineering  discipline  is  the  transformational  programming  paradigm  where  software 
is  developed  and  maintained  at  the  formal  specification  level  and  provably  correct  code  is  auto¬ 
matically  derived  from  the  specification  (42).  This  paradigm  is  inherently  knowledge-based  and 
requires  two  types  of  software  engineering  knowledge:  design  knowledge  and  domain  knowledge. 
Design  knowledge  incorporates  the  domain  independent  knowledge  required  to  produce  software 
including  knowledge  of  architectures,  algorithms,  and  data  structures.  Domain  knowledge,  on  the 
other  hand,  captures  knowledge  about  objects  in  the  problem  domain.  In  the  transformational 
programming  paradigm,  software  engineers  use  domain  knowledge  to  derive  system  specifications 
from  domain  models  and  then  use  design  knowledge  to  produce  the  code.  Thus,  software  engi¬ 
neering  evolves  from  the  art  of  programming  to  the  development  of  the  domain  models  and  design 
knowledge  necessary  to  derive  provably  correct  software  (68:634). 

Use  of  algebraic  theories  to  represent  software  engineering  knowledge  has  gained  momentum 
during  the  last  decade.  Some  of  the  most  promising  work  is  using  theory-based  specifications 
to  drive  software  synthesis  systems.  A  notable  example  of  such  a  synthesis  system,  the  Kestrel 
Interactive  Development  System  (KIDS)  (86),  has  yielded  some  exciting  results.  KIDS  has  been 
used  to  derive  dozens  of  algorithms  including  a  transportation  scheduling  algorithm  for  over  15,000 
movements  that  was  78  percent  faster  and  had  75  percent  fewer  delays  than  the  best  previously 
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known  algorithms  (87).  A  follow-on  effort  to  KIDS,  Specware  (55),  supports  a  systematic  approach 
to  the  composition  of  theory-based  specifications  followed  by  their  stepwise  refinement  into  code. 
The  basic  synthesis  steps  are  to  1)  develop  a  domain  theory  for  the  problem  to  be  solved,  2)  create 
a  specification  describing  the  problem  in  the  language  of  its  domain  theory,  3)  apply  specification 
refinements  to  construct  a  program-based  model  of  the  problem  specification,  4)  apply  program 
optimizations,  and  5)  compile  the  program  (86). 

While  systems  such  as  KIDS  and  Specware  have  been  making  progress  in  software  synthesis 
research  (steps  3  and  4  above),  research  in  the  acquisition  of  formal  specifications  (steps  1  and 
2)  has  not  been  keeping  pace.  Formal  software  specification  has  long  been  touted  as  a  way  to 
increase  the  quality  and  reliability  of  software;  however,  it  remains  an  intricate,  manually  intensive 
activity.  Besides  driving  software  synthesis  systems  as  described  above,  justifications  for  using 
formal  software  specifications  also  include  clarifying  customer  requirements,  avoiding  ambiguities 
and  contradictions,  and  the  ability  to  rigorously  verify  certain  properties  (29:74).  In  fact,  experience 
in  the  use  of  formal  methods  suggests  that  the  cost  of  using  formal  methods  is  no  greater,  and 
possibly  even  less,  than  using  traditional  software  development  methods  (44:17).  Yet,  to  date, 
formal  methods  are  not  widely  accepted.  Fraser  suggests  several  reasons  for  this  lack  of  acceptance 
and  use  (29:75,76): 

1.  Lack  of  research  directed  at  developing  practical  methods  and  tools  for  incorporating  for¬ 
mal  methods  into  the  software  life-cycle.  Most  formal  methods  research  is  based  on  formal 
languages  and  inference  rules. 

2.  Little  expertise  among  practicing  software  developers  in  the  mathematical  and  logical  concepts 
and  notations  used  in  most  formal  specification  languages. 

3.  Unsuitability  of  formal  notation  for  communicating  with  end  users  since  they  are  even  less 
likely  than  the  developer  to  be  trained  in  formal  mathematical  and  logical  concepts. 

4.  Tendency  of  formal  notations  to  inhibit  creativity  in  a  poorly  defined  problem  areas. 
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5.  Unwillingness  of  management  to  make  a  sizeable  investment  in  what  they  consider  to  be  an 

unproven  technology. 

So,  what  is  the  solution?  Fraser  suggests  that  a  Computer-Assisted  Parallel  Successive  Refine¬ 
ment  methodology  is  the  answer.  In  a  computer-assisted  parallel  successive  refinement  method,  the 
designers  use  both  semi-formal  (graphical)  and  formal  representations  to  produce  the  specification 
by  successively  performing  refinements  to  both  representations  in  parallel  (29:83).  This  method¬ 
ology  directly  addresses  items  1,  3,  and  4  above  and  aids  in  resolving  problems  associated  with  2 
and  5.  Both  users  and  software  personnel  unaccustomed  to  formal  specifications  have  access  to  the 
semi-formal,  graphical  representation  while  the  formal  representation,  and  its  associated  benefits, 
is  maintained.  The  formal  representation  is  used  by  knowledgeable  software  personnel  and  auto¬ 
mated  tools  to  check  for  ambiguities  and  contradictions  and  aid  in  transforming  the  specification 
into  code.  Unfortunately,  Fraser  reports  that  there  has  been  no  work  in  this  area  (29:83). 

1.2  Overview 

The  basic  premise  of  this  investigation  is  that  formal  software  specifications  can  be  constructed 
using  a  computer-assisted  parallel  successive  refinement  approach  incorporating  correctness  preserv¬ 
ing  transformations  to  automatically  translate  between  graphically-based  object-oriented  represen¬ 
tations  and  their  corresponding  formal  representation.  There  are  two  obvious  starting  points  for 
this  investigation:  object-oriented  representations  and  formal  representations. 

Because  a  standard  set  of  definitions  does  not  yet  exist  for  many  terms  and  concepts  in  object- 
orientation,  a  specific  object-oriented  model  was  selected  before  continuing  the  investigation.  There 
are  several  proposed  object-oriented  methodologies  in  use  today  (1,  4,  11,  13,  15,  19,  20,  21,  72, 
73,  84,  98,  103).  Rumbaugh’s  Object  Modeling  Technique  (OMT)  (83)  was  chosen  for  its  breadth 
of  coverage,  availability  of  tools,  and  usefulness  in  domain  analysis  and  modeling.  Rumbaugh  uses 
three  distinct  views  to  describe  a  domain:  (1)  the  object  model  describes  structural  relationships 
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between  domain  objects,  (2)  the  dynamic  model  describes  interactions  between  domain  objects, 
and  (3)  the  functional  model  describes  how  processes  in  the  domain  transform  data.  To  enable 
automated  translation  of  these  models  into  a  formal  representation,  a  formal  semantics  for  each 
model  was  developed.  Then,  an  abstract  syntax  tree  (AST)  representation  of  a  generic  OMT 
specification  was  developed  that  captures  the  three  OMT  models  in  a  single  unifying  structure. 

Theory-based  algebraic  specification  is  concerned  with  (1)  modeling  system  behavior  using 
algebras  (a  collection  of  values  and  operations  on  those  values)  and  axioms  that  characterize  algebra 
behavior,  and  (2)  composition  of  larger  specifications  from  smaller  specifications.  Composition 
of  specifications  is  accomplished  via  specification  building  operations  defined  by  category  theory 
constructs  (88).  In  algebraic  specifications,  the  structure  of  a  specification  is  defined  in  terms  of 
sorts,  abstract  collections  of  values,  and  operations  over  those  sorts.  This  structure  is  called  a 
signature.  A  signature  describes  the  structure  of  a  solution;  however,  a  signature  does  not  specify 
semantics.  To  specify  semantics,  the  definition  of  a  signature  is  extended  with  axioms  defining 
the  intended  semantics  of  signature  operations.  A  signature  with  associated  axioms  is  called  a 
specification. 

Algebraic  specifications  are  used  in  this  investigation  to  define  a  theory-based  model  of  object- 
orientation.  Formal  definitions  for  classes  and  objects  were  defined  within  this  model.  General  class 
relationships  were  investigated  resulting  in  the  definition  of  formal  techniques  for  the  construction  of 
valid  inheritance,  aggregation,  and  association  relationships.  An  object-oriented  algebraic  specifica¬ 
tion  language,  0-Slang,  was  developed  that  incorporates  the  category  theory  operations  necessary 
to  define  relationships  between  object  classes.  Finally,  formal  translations  were  defined  that  map 
generic  OMT  specifications  into  0-Slang  algebraic  specifications. 

The  feasibility  of  translating  graphically-based  OMT  models  into  algebraic  specifications  was 
demonstrated  by  the  development  of  an  automated  transformation  system.  The  prototype  system 
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uses  a  commercial  OMT  modeling  tool  as  the  front  end  to  a  rule-based  transformation  system  that 
generates  0-Slang  based  on  the  formal  translations. 

Related  work  is  described  in  the  next  section  while  Section  1.4  defines  the  basic  assumptions 
upon  which  this  investigation  is  based,  Section  1.5  describes  the  contributions  of  the  investigation, 
and  Section  1.6  outlines  the  sequence  of  presentation  for  the  rest  of  this  document. 

1.3  Related  Work 

This  section  describes  research  related  to  my  investigation.  Section  1.3.1  describes  proposed 
methods  for  incorporating  formal  specifications  into  current  software  development  practices,  Sec¬ 
tion  1.3.2  presents  some  formal  specification  languages  used  to  describe  object-oriented  systems, 
and  Section  1.3.3  describes  existing  transformation  systems. 

1.3.1  Formal  Specification  Incorporation  Methodologies.  Several  authors  have  proposed 
techniques  for  incorporating  formal  methods  into  existing  software  development  practices.  Fraser 
et.  al.  created  a  framework  for  analyzing  these  methods  (29).  They  categorize  the  methods  by 
the  formalization  process  and  the  formalization  support  of  each  of  the  methods.  The  formalization 
process  can  be  defined  as  either  being  direct,  where  software  developers  move  directly  from  informal 
(natural  language)  specifications  to  formal  specifications  without  going  through  any  semi-formal 
activity,  and  transitional,  where  the  transformation  from  informal  to  formal  specifications  uses  an 
intermediate  semi-formal  specification.  Within  the  transitional  process,  Fraser  defines  two  subtypes: 
sequential  and  parallel  successive  refinement.  In  a  sequential  transitional  approach,  the  semi- 
formal  specifications  are  fully  defined  and  then  transformed  into  a  formal  specification.  In  the 
parallel  successive  refinement  approach,  the  semi-formal  and  formal  specifications  are  produced 
simultaneously,  going  through  equivalent  successive  refinements.  Formalization  support  is  also 
divided  into  two  categories:  unassisted,  where  all  work  is  done  manually,  and  computer  assisted 
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where  computer-based  heuristics  or  knowledge-based  transformation  tools  assist  the  developer.  I 
briefly  discuss  a  number  of  methodologies  and  then  show  how  they  fit  into  Fraser’s  framework. 

Andrews  and  Gibbons  describe  a  methodology  where  Structured  Analysis  is  used  to  build  a 
hierarchical  system  structure  chart.  This  structure  chart  is  then  translated  manually  into  VDM. 
Once  in  VDM,  the  structure  chart  is  used  to  guide  the  decomposition  of  operations  and  data 
refinements  (29). 

Babin,  Dustman,  and  Shoval  propose  a  computer  assisted  method  based  on  the  ADISSA 
method,  which  is  an  extension  of  Structured  System  Analysis.  In  ADISSA,  the  system  architecture 
is  described  via  a  set  of  transactions  that  model  system  events  and  user  requests.  Flow  of  control  is 
modeled  by  a  finite  state  machine.  The  method  uses  a  ruled-based  transformation  system  to  help 
transform  the  semi-formal  specification  into  a  formal  specification  (10). 

Conger  et.  al.  developed  a  manual  procedure  for  taking  Structured  Analysis  data  flow 
diagrams  and  transforming  them  into  VDM.  First,  hierarchical  data  flow  diagrams  are  developed 
using  Structured  Analysis  heuristics.  The  data  flow  diagrams  are  then  used  to  guide  the  developer 
in  partitioning  and  stepwise  refining  of  the  VDM  specifications.  A  VDM  specification  is  produced 
for  each  data  transformation  process  in  the  data  flow  diagram  set  (22). 

Fraser,  Kumar,  and  Vaishnavi  propose  an  interactive,  rule-based  transformation  system  to 
translate  Structured  Analysis  specifications  into  VDM  specifications.  The  method  is  based  on 
data  flow  diagrams  and  decision  tables  produced  via  Structured  Analysis.  The  bottom  level  data 
flow  transformation  processes  are  defined  by  decision  tables  which  are  then  transformed  by  the 
rule-based  system  (28). 

Kemmerer  describes  a  process  which  integrates  traditional  software  development  with  de¬ 
velopment  using  formal  methods.  In  this  process,  the  formal  methods  are  annotations  to  the 
semi-formal  design  and  are  developed  directly  from  lower-level  natural  language  descriptions  (52). 
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Kung  has  developed  Process  Interface  Modules  which  are  formal  descriptions  of  the  commu¬ 
nication  and  synchronization  among  processes.  Basically,  the  system  is  initially  developed  using 
entity  relationship  diagrams  to  describe  the  static  parts  of  the  system  and  data  flow  diagrams  to 
model  the  dynamic  parts  of  the  system.  This  set  of  diagrams  is  then  manually  transformed  into 
Process  Interface  Modules  to  provide  formal  proof-based  checking  of  the  semi-formal  design  (57). 

Miriyala  and  Harandi  have  developed  an  automated  tool  to  help  interactively  create  formal 
specifications  directly  from  informal  requirements  specified  in  a  natural  language  subset.  The 
tool  develops  a  problem  structure  tree  directly  from  the  informal  specification  and  uses  domain 
independent  knowledge  and  analogy  with  past  developments  to  guide  the  refinement  of  the  tree 
(74). 

Wing  proposes  a  very  vague  method  where  informal  requirements  are  transformed  into  a 
formal  specification  through  a  series  of  iterative  interviews  with  the  user.  She  proposes  neither  a 
semi-formal  method  to  communicate  with  the  user  nor  a  specific  formal  specification  language  to 
work  toward  (102). 

Table  1.1  classifies  the  methodologies  discussed  above  according  to  Fraser’s  framework.  As 
shown,  and  as  reiterated  by  Fraser,  the  lower  right  hand  corner,  computer  assisted,  parallel  suc¬ 
cessive  refinement  methodologies,  has  seen  no  research  to  date.  According  to  Fraser,  work  in 
developing  techniques  and  methodologies  for  this  area  is  needed  because  of  the  promise  of  the 
approach  (29:84). 

1.3.2  Formal  Specification  Languages. 

1.3. 2.1  Z  Extensions.  There  have  been  a  number  of  Z  extensions  designed  to  make 
Z  specifications  easier  to  understand.  Many  of  these  extensions  are  object-oriented.  Although  most 
of  the  object-oriented  Z  extensions  provide  techniques  for  structuring  the  Z  specification  using  the 
common  object-oriented  concepts,  they  do  not  attempt  to  provide  an  improvement  in  specification 
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development  methodology.  A  number  of  Z  extensions  are  discussed  below.  However,  to  avoid 
repetition,  only  the  unique  features  of  each  language  are  discussed. 

MooZ.  MooZ  is  an  object-oriented  extension  of  Z.  A  MooZ  specification  is 
defined  as  a  set  of  MooZ  class  specifications  which  are  semantically  described  as  records.  These 
classes  are  then  used  to  define  data  types  or  generic  templates  from  which  to  instantiate  objects. 
MooZ  classes  support  parameterization  and  multiple  inheritance.  Attributes  determine  the  state 
of  an  object  and  these  attributes  may  be  visible  or  hidden.  Operations  that  manipulate  these  state 
attributes  are  handled  at  the  individual  object  level;  however,  operations  such  as  create  or  destroy, 
which  do  not  reference  state  variables,  are  handled  by  the  class.  Operations  and  attributes  are 
implemented  via  functions  that  are  defined  in  the  Z  axiomatic  style  (62). 

Object-Z.  Object-Z  is  another  object-oriented  extension  to  Z.  Like  MooZ  de¬ 
scribed  above,  Object-Z  uses  a  class  definition  which  includes  attributes  and  operations  which  are 
defined  using  Z  axiomatic  definitions.  One  unique  aspect  of  Object-Z  is  its  use  of  a  history  in¬ 
variant.  The  history  invariant  uses  linear  temporal  logic  to  further  restrict  valid  object  behavior 
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by  defining  legal  sequences  of  operation  calls  (17).  Object-Z  also  includes  referential  semantics 
which  allows  the  declaration  of  references  (pointers)  to  objects.  These  semantics  are  particularly 
useful  in  creating  aggregates  where  one  might  define  an  object  as  a  variable,  or  even  define  a  set  of 
objects.  Object-Z  also  provides  a  promotion  operation  which  allows  the  operation  of  an  aggregate 
component  to  be  promoted  to  an  operation  of  the  aggregate  class  (82:114). 

Z++.  Z++  is  another  object-oriented  extension  based  on  Z.  However,  Z-b- 1- 

is  unique  in  that  its  semantics  is  based  on  algebra  and  category  theory.  In  Z++,  classes  form  a 
category  with  Z++  class  refinements  defined  as  the  arrows.  The  formal  algebraic  and  categorical 
basis  makes  it  possible  to  prove  specific  properties  about  Z-t— I-  specifications  (60:28).  To  keep  Z++ 
consistent  with  the  Z  community,  a  model-based  theory  has  been  developed  to  enable  reasoning 
using  either  algebraic  or  model-based  semantics  (58).  While  Z++  semantics  are  based  on  algebra 
and  category  theory  operations,  Z-f-+  does  not  use  category  theory  operations  to  build  new  specifi¬ 
cations  or  compose  new  specifications  from  existing  specifications.  Z-b- 1-  must  be  written  manually. 
Category  theory  is  only  used  to  prove  correctness  of  specification  structure. 

1. 3.2.2  OBJS,  OOZE,  and  FOOPS.  Despite  its  name  and  its  use  of  the  term 
“objects”,  OBJS  is  not  an  object-oriented  language;  however,  it  has  been  extended  to  include 
object-oriented  concepts  and  does  have  many  interesting  aspects.  Actually,  OBJS  is  not  simply 
a  language,  but  a  system  which  includes  a  functional  programming  language,  environment,  and 
interpreter  for  algebraic  specifications  (40).  OBJS  includes  three  types  of  components:  objects, 
theories,  and,  views.  Objects  are  not  objects  in  the  object-oriented  sense,  but  are  actually  purely 
functional  executable  code  modules.  Theories,  on  the  other  hand,  are  similar  to  the  concept  of 
theories  as  defined  in  Section  S.2  in  relation  to  algebraic  specifications.  Views  are  used  in  OBJS 
to  relate  how  objects  (modules)  satisfy  axioms  of  a  particular  theory  and  are  defined  as  theory 
morphisms  (S8:4S6).  Although  OBJS  uses  theories,  it  was  developed  to  perform  code-level  reuse 
by  composing  existing  code  and  not  for  transformational  derivation  of  code  from  specifications. 
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0BJ3  is  based  on  order-sorted  algebras  which  is  an  extension  of  many-sorted  algebras  (39). 
Basically,  an  order-sorted  algebra  is  a  many-sorted  algebra  with  a  partial  order  defined  on  the  sorts. 
According  to  Goguen,  order-sorted  algebras  are  used  to  allow  sorts  to  be  of  two  different  types  (40:4). 
For  example,  a  natural  number  is  an  integer,  an  integer  is  a  rational  number,  and  a  rational  number 
is  a  real  number.  This  gives  a  subsort  partial  ordering  of  natural  <  integer  <  rational  <  real. 
This  allows  the  definition  of  total  functions  on  subsorts  that  otherwise  would  be  defined  as  partial 
functions. 

As  a  final  note,  and  to  make  a  clear  distinction  between  OBJ3  and  object-oriented  languages, 
Goguen  states  that  OBJ3  objects  do  not  have  states  (40:37)  which  is  a  critical  aspect  of  object- 
orientation.  Although  it  provides  many  of  the  same  operations  necessary  for  class  inheritance  and 
parameterization,  without  providing  state  it  can  only  produce  functional  specifications. 

OOZE  (Object-Oriented  Z  Extension)  (6,  7)  and  FOOPS  (Functional  Object-Oriented  Pro¬ 
gramming  System)  (37)  are  object-oriented  specification  languages  based  on  OBJ3.  Because  OOZE 
is  a  syntactic  variant  of  FOOPS  and  has  the  same  semantics  (5:181),  I  only  discuss  FOOPS  here. 
FOOPS  is  an  algebraic,  object-oriented  specification  language  based  on  OBJ3.  It  provides  classes 
(possibly  parameterized),  objects,  inheritance,  attributes,  and  methods.  Objects  are  the  instances 
of  a  class,  and  each  class  may  have  a  number  of  objects.  Each  object  has  a  unique  identifier,  a  set 
of  observable  attributes,  and  a  set  of  methods  which  change  the  state  of  an  object  (38:441). 

1.3. 2.3  Larch.  Larch  is  a  two-tiered  algebraic  specification  language  based  on 
multi-sorted  first-order  logic  with  equality  (43:8).  Each  specification  has  two  parts,  a  language 
specific  specification  written  in  one  of  a  number  of  Larch  interface  languages  (LIL),  and  a  language 
independent  part  written  in  the  Larch  Shared  Language  (LSL).  Larch  is  not  intended  to  be  object- 
oriented  although  object-oriented  designs  have  been  mapped  into  Larch  (65).  LSL  specification 
entities,  called  traits,  define  a  set  of  operations  over  a  set  of  sorts. 
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LSL  traits  can  be  parameterized  on  sorts  and  sorts  are  defined  by  their  use  in  defining  opera¬ 
tions.  Larch  is  designed  to  be  used  to  prove  semantic  properties  about  specifications  and  not  to  be 
transformable  into  code  or  to  be  executable;  therefore,  Larch  provides  an  implies  section  of  a  trait 
to  make  explicit  claims  about  theory  containment  (i.e.,  what  theorems  are  logical  consequences  of 
the  trait  assertions).  These  claims  must  be  proved  by  the  author  and  are  useful  in  error  detection 
and  reader  understanding. 

The  Larch  interface  languages  are  used  to  define  the  mapping  between  an  actual  programming 
language  and  an  LSL  trait.  Whereas  the  traits  are  used  to  define  the  functional  aspects  of  the 
operations,  an  interface  specification  provides  the  programming  language  interface  to  the  trait  and 
models  state  as  represented  in  the  programming  language.  Usually  this  state  modeling  involves 
specifying  the  state  before  and  after  each  operation. 

1.3. 2.4  Slang.  Slang  is  an  algebraic  specification  language  where  specifications  are 
theory  presentations  using  higher  order  logic  extended  with  category  operations  such  as  products, 
coproducts,  quotients,  and  subsorts  (54).  System-level  specifications  are  developed  by  building 
diagrams  which  can  be  used  to  express  parameterization,  instantiation,  importation,  and  refinement 
(50).  Specification  building  operations  include  translation,  colimit,  and  importation,  each  of  which 
defines  a  morphism  (or  in  the  case  of  a  colimit,  morphisms)  between  a  source  specification  and  a 
target  specification.  Translation  copies  a  specification  while  renaming  some  or  all  of  the  sorts  or 
operations.  The  colimit  operation  takes  the  colimit  of  a  number  of  specifications  and  morphisms 
between  them,  combining  them  over  any  “shared”  sorts  and  operations,  into  a  single  specification. 
Importation  involves  including  another  specification  -  sorts,  operations,  and  axioms  -  into  a  new 
specification  where  additional  sorts,  operations,  and  axioms  can  be  defined. 

Diagrams  are  critical  to  specification  development  in  Slang.  In  Slang,  diagrams  are  “a  multi- 
directed  graph  whose  nodes  are  labeled  with  specifications  and  whose  arcs  are  labeled  with  mor¬ 
phisms”  (54:18).  In  a  diagram  definition,  the  arcs  define  the  morphisms  between  the  specifications. 
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Cocone-morphisms  are  created  by  a  colimit  operation  while  import-morphisms  and  translation- 


morphisms  are  created  via  the  import  and  translate  operations  respectively. 

The  colimit,  import,  and  translate  operations  available  in  Slang  are  similar  to  the  constructs 
used  in  OBJ3  to  construct  specifications  while  the  ability  to  refine  specifications,  using  interpre¬ 
tations  built  into  Slang  provides  an  even  more  powerful  framework  for  deriving  correct  programs 
directly  from  the  specifications.  An  interpretation  from  specification  B  to  specification  A  provides 
a  mechanism  for  constructing  a  model  of  A  from  models  of  B.  Thus  if  we  have  a  model  for  spec¬ 
ification  B  and  can  construct  an  interpretation  from  JB  to  a  A,  we  can  create  a  model  for  A  as 
well. 


1.S.3  Transformation  Systems. 

1.3. 3.1  Bourdeau  and  Cheng.  Bourdeau  and  Cheng  (14)  have  developed  formal 
semantics  for  an  extended  version  of  the  OMT  object  model  notation  using  the  Larch  specification 
language  (43)  to  describe  modular  algebraic  specifications.  The  object  model  itself  is  a  specification 
which  simply  “includes”  the  object  classes  and  associations  derived  from  the  object  diagram. 

Classes  and  associations  are  defined  using  a  set  of  semi-formal  rules.  According  to  these  rules, 
each  class  defines  a  Larch  specification  called  a  trait.  Within  a  class  trait,  sorts  are  introduced  to 
represent  objects  in  the  class  as  well  as  the  state  of  an  object  in  the  class.  A  special  state  evaluation 
function  is  added  to  map  a  given  object  to  a  value  in  the  state  sort.  For  each  attribute  in  the  class, 
a  function  is  defined  which  takes  an  object  value  and  returns  the  value  associated  with  the  object. 

Relational  aspects  of  the  object  model  such  as  association,  aggregation,  and  inheritance  are 
defined  as  predicates.  Each  component  in  an  aggregate  relation  defines  a  has-part  predicate  that, 
given  two  objects,  determines  if  the  two  objects  are  in  the  relation.  Likewise,  each  association 
defines  a  predicate  R  in  an  association  trait  that  determines  if  two  objects  are  related  via  the 
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association.  Aggregate  and  association  multiplicities  are  defined  as  axioms  over  the  appropriate 
predicates. 

Inheritance  is  modeled  by  defining  a  simulates  operation  that  takes  an  object  of  the  subtype 
and  produces  an  object  of  the  supertype,  thus  implementing  Bourdeau  and  Cheng’s  interpretation 
of  the  substitution  property.  For  their  definition  of  inheritance,  Bourdeau  and  Cheng  assume  that 
a  subclass  object  D  must  be  substitutable  for  its  superclass  object  C  at  any  point  in  the  object’s 
lifetime.  To  satisfy  this  notion  of  inheritance,  Bourdeau  and  Cheng  define  constraints  on  the 
simulates  operation  that  requires  all  states  in  the  subclass  to  map  some  state  in  the  superclass  and 
that  for  all  attributes  defined  in  the  superclass,  the  values  of  those  attributes  in  the  subclass  are 
allowable  values  in  the  superclass. 

Once  a  specification  for  an  object  model  is  derived,  Bourdeau  and  Cheng  use  OMT  instance 
models  (diagrams  which  show  how  a  particular  set  of  objects  relate  to  each  other)  to  define  a  set  of 
algebras.  They  define  the  semantics  of  the  object  model  as  the  complete  set  of  instance  diagrams 
that  are  consistent  with  the  object  model  specification. 

1.3. 3. 2  Rafsanjani  and  Colwill.  Rafsanjani  and  Colwill  have  defined  a  mapping 
from  Object-Z  to  C++  in  the  context  of  an  abstract  object  model  (81).  They  define  their  mapping 
informally  without  thought  toward  automation  and  their  approach  is  based  on  empirical  cases  and 
is  not  theoretically  well  founded  (i.e.,  there  is  no  proof  that  the  C++  implementation  does  in  fact 
correctly  represent  the  specification).  Their  mapping  is  purely  structural.  There  is  no  attempt  to 
transform  the  semantics  of  the  specification  into  code.  This  is  left  as  a  “creative”  exercise  for  the 
programmer. 

Although  the  goals  of  their  research  differ  from  this  investigation,  their  work  has  some  inter¬ 
esting  aspects.  First  is  the  use  of  an  object  model  to  capture  features  common  to  both  languages. 
The  object  model  allows  them  to  relate  concepts  between  the  two  languages  and  define  a  mapping. 
Although  Object-Z  operations  are  mapped  to  virtual  C++  functions  which  allow  the  inheriting 
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class  to  modify  the  functions  defined  in  the  parent  class,  Rafsanjani  and  Colwill  view  inheritance 
strictly,  allowing  only  for  extension  or  restriction.  Unfortunately,  this  view  of  inheritance  is  only 
enforced  by  the  good  will  of  the  programmer.  Object-Z  predicates  are  used  to  represent  restrictions 
on  attributes  and  state  spaces  as  well  to  define  operation  pre-  and  post-conditions.  Rafsanjani  and 
Colwill  map  these  predicates  to  C-b- 1-  functions  which  are  invoked  before  and  after  each  operation 
to  ensure  the  predicates  remain  true. 

1.3. 3. 3  KIDS.  The  Kestrel  Interactive  Development  System  (KIDS)  is  a  proto¬ 
type  system  that  provides  semi-automatic  derivation  of  programs  from  algebraic  specifications. 
KIDS  maps  program  specifications  to  algorithm  theories  to  instantiate  a  functional  program  and 
then  uses  high-level  optimization  operations  to  produce  an  efficient  and  correct-by-construction 
program  (with  respect  to  the  initial  specification)  (53).  Operations  provided  by  KIDS  include 
algorithm  design,  deductive  inference,  context  independent  and  context  dependent  simplification, 
partial  evaluation,  finite  differencing,  and  compilation.  KIDS  is  based  on  the  use  of  algebraic 
theories  and  category  theory  operations.  Theories  are  used  in  KIDS  to  encapsulate  knowledge 
about  problems  in  general,  knowledge  about  the  problem  being  solved,  general  knowledge  about 
the  application  domain,  and  general  programming  knowledge.  Category  theory  concepts  and  op¬ 
erations  such  as  pushouts,  colimits,  and  morphisms  are  used  to  combine  and  refine  these  theories 
into  efficient  programs. 

The  basic  steps  in  deriving  a  program  in  KIDS  are  1)  to  develop  (or  reuse)  a  domain  theory 
for  the  problem  to  be  solved,  2)  create  a  specification  that  describes  the  problem  to  be  solved  in  the 
language  of  its  domain  theory,  3)  apply  a  design  tactic  which  forms  an  interpretation  of  the  problem 
specification  in  general  algorithm  theory  and  instantiates  a  program,  4)  apply  optimizations  to  the 
program,  and  5)  compile  the  program  (86:1025).  Application  of  this  approach  has  yielded  some 
impressive  results.  KIDS  has  been  used  to  derive  dozens  of  algorithms  including  real-world  systems. 
KIDS  has  produced  a  transportation  scheduling  algorithm  for  over  15,000  individual  movements 
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that  was  78  percent  faster  and  produced  75  percent  fewer  delays  than  the  best  algorithms  previously 
known  (87:66).  KIDS  has  shown  that  not  only  is  transformational  program  derivation  possible,  but 
it  can  produce  more  efficient  and  more  reliable  software. 

1.3. 3. 4  Specware.  Specware  (55)  is  a  transformational  program  derivation  system 
based  on  Slang  (54)  and  KIDS.  Specware  extends  the  concepts  used  in  KIDS  by  allowing  the 
developer  to  build  diagrams  of  specifications  to  build  up  a  domain  theory  and  eventually  a  system 
specification.  Basically,  Specware  provides  the  automated  tool  support  for  developing  specifications 
in  the  Slang  specification  language  described  above.  When  completed,  Specware  will  incorporate 
facilities  to  provide  algorithm  design  and  optimization,  data  type  refinement,  integration  of  reactive 
system  components,  and  code  generation. 

1.4  Assumptions 

Because  this  research  involves  the  use  of  specifications  entered  by  an  unknown  user,  two 
assumptions  are  made  concerning  the  specifications  entered. 

Assumption  I.l  Initial  Specification  Consistency.  All  specifications,  as  entered  by  the  user,  are 
correct  and  consistent. 

If  a  specification  is  not  internally  consistent,  then  valid  models  of  those  specifications  do 
not  exist  (32:3-13);  therefore,  internal  consistency  is  a  requirement  for  formal  software  synthesis. 
Unfortunately,  Church  and  Turing  independently  showed  that  in  general,  proving  that  a  set  of  first 
order  axioms  are  inconsistent  is  not  possible  (18:45).  Therefore,  in  this  research,  I  assume  that 
user  provided  specifications  are  consistent  and  only  show  that  further  specification  composition 
operations  (inheritance,  aggregation,  etc.)  maintain  that  consistency. 

Assumption  1.2  Restricted  Use.  All  OMT  models  developed  by  the  user  are  developed  in  accor¬ 
dance  with  the  restricted  models  as  defined  in  Chapter  V. 
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As  defined  by  Rumbaugh,  OMT  has  numerous  ways  to  specify  the  same  features  using  formal 
and  informal  techniques.  In  this  investigation,  specification  using  informal  techniques  are  inade¬ 
quate  for  automatic  translation  while  the  ability  to  specify  the  same  functionality  using  multiple 
techniques  ultimately  leads  to  consistency  questions.  Therefore,  Chapter  V  defines  a  restricted 
version  of  OMT’s  three  models  and  limits  how  they  are  used. 

1.5  Contributions 

Based  on  these  assumptions,  the  contributions  of  this  research  include: 

1.  Development  of  an  algebraic,  category  theory  based  specification  language  with  built-in  con¬ 
structs  for  object-oriented  concepts  such  as  classes,  inheritance,  aggregation,  association,  and 
global  event  communication. 

2.  Formalization  of  basic  object-oriented  concepts  using  algebraic  and  category  theory  con¬ 
structs. 

3.  Formalization  of  a  generally  accepted  notion  of  class  inheritance  and  a  sufficiency  criteria  for 
proving  adherence  to  that  formalization. 

4.  Formalization  of  the  semantics  of  the  object,  dynamic,  and  functional  OMT  models. 

5.  Formalization  of  event-based  communications  paths  within  an  OMT  domain  specification. 

6.  Formdization  of  translations  from  graphically-based  object-oriented  representations  to  alge¬ 
braic  specifications. 

7.  Elevation  of  the  level  of  abstraction  at  which  formal  specifications  are  developed. 

8.  Development  of  techniques  to  ensure  consistency  of  object-oriented  specification  composition. 

9.  Elevation  of  the  acceptance  of  formal  specifications  and  methods. 
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1.6  Summary 


This  chapter  is  an  introduction  to  the  goals  and  objectives  of  my  investigation  and  a  brief 
overview  of  related  research.  The  remainder  of  this  dissertation  is  organized  as  follows: 

•  Chapter  II  presents  a  framework  for  the  parallel  acquisition  of  theory-based  specifications 
using  graphically-based  object-oriented  concepts. 

•  Chapter  III  discusses  basic  algebraic  specification  construction  techniques  within  a  category 
theory  setting. 

•  Chapter  IV  establishes  the  foundations  for  a  theory-based  model  of  object-orientation. 

•  Chapter  V  defines  the  formal  semantics  for  the  OMT  object,  dynamic,  and  functional  models. 

•  Chapter  VI  introduces  a  theory-based  model  of  object-orientation  based  on  the  OMT  object, 
dynamic,  and  functional  models. 

•  Chapter  VII  describes  the  formal  translations  from  a  generic  OMT  specification  to  a  theory- 
based  specification. 

•  Chapter  VIII  demonstrates  the  feasibility  of  automated  specification  translation  by  producing 
two  theory-based  domain  specifications  using  an  automated  proof-of-concept  system. 

•  Chapter  IX  contains  the  conclusions  from  this  investigation  and  provides  recommendations 
for  future  research. 
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II.  Software  Development  and  Specification  Acquisition  Framework 

2.1  Overview 

This  chapter  defines  a  theory-based  Specification  Acquisition  Mechanism  based  on  an  object- 
oriented  user  interface  and  theory-based  specifications.  The  basic  concept  is  to  allow  system  de¬ 
velopers  to  graphically  specify  domain,  architecture,  and  system-level  details  in  an  object-oriented 
fashion  and  automatically  convert  them  into  theory-based  algebraic  specifications.  Section  2.1.1 
describes  the  basic  software  development  framework  into  which  the  theory-based  Specification  Ac¬ 
quisition  Mechanism  fits  while  Section  2.1.2  presents  an  overview  of  the  Specification  Acquisition 
Mechanism  itself.  Sections  2.2,  2.3,  and  2.4  further  define  specific  subsystems  of  the  Specification 
Acquisition  Mechanism. 

2.1.1  Software  Development  Framework.  A  framework  for  the  development  of  software 
using  semi-automated  software  synthesis  from  theory-based  system  specifications  is  shown  in  Fig¬ 
ure  2.1. 
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Figure  2.1  Software  Development  Framework 

The  central  theme  behind  the  proposed  software  development  framework  is  the  synthesis  of  soft¬ 
ware  from  theory-based  specifications.  Functional  specifications  are  developed  and  combined  with 
architecture  theories  in  the  Specification  Acquisition  Mechanism  to  create  theory-based  system 
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specifications.  These  specifications  are  then  fed  into  the  Design  Refinement  Mechanism  where  the 
sorts,  operations,  and  architectures  are  refined  and  mapped  to  an  intermediate  abstract  target  lan¬ 
guage  (ATL)  representation.  This  ATL  is  then  converted  into  compilable  source  code  and  optimized 
in  the  Generation  &  Optimization  Mechanism.  This  research  focuses  mainly  on  the  Specification 
Acquisition  Mechanism  and  the  Library  of  Class  Theories.  The  Design  Refinement  and  Genera¬ 
tion  &  Optimization  mechanisms  are  only  discussed  informally  in  this  chapter  and  left  for  future 
research.  This  research  focuses  on  one  approach  to  the  Specification  Acquisition  Mechanism. 

2.1.2  Specification  Acquisition  Mechanism.  The  basic  functions  and  data  fiows  of  the 
proposed  Specification  Acquisition  Mechanism  are  shown  in  Figure  2.2.  There  are  three  phases  to 
acquiring  a  theory-based  system  specification  using  this  mechanism:  Domain  Engineering,  Speci¬ 
fication  Generation,  and  Specification  Structuring.  Each  phase  of  specification  acquisition  has  an 
associated  theory-based  subsystem  that  accesses  the  Theory  Library.  However,  to  simplify  specifi¬ 
cation  acquisition,  the  domain  engineer  or  system  analyst  uses  a  graphically-based  object-oriented 
interface.  For  the  purposes  of  researching  and  prototyping,  I  have  chosen  to  base  my  object- 
oriented  approach  on  the  Rumbaugh’s  OMT.  OMT  was  chosen  due  to  its  popularity,  breadth  of 
coverage,  and  availability  of  tools.  I  do  not  claim  that  OMT  is  the  best,  or  even  better  than  other 
object-oriented  methods  or  techniques. 

The  Specification  Acquisition  Mechanism  is  designed  to  help  produce  consistent  theory-based 
domain  models  which  are  then  refined  into  functional  system  specifications.  (I  use  the  term  “func¬ 
tional  specification”  here  to  describe  the  definition  of  the  system  functions.  It  does  not  imply  a 
shift  from  an  object-oriented  to  a  functional  view  of  the  system.)  A  domain  model  is  the  “spe¬ 
cific  representation  of  appropriate  aspects  of  an  application  domain”  (48)  and  may  take  on  various 
forms  including  domain  taxonomies,  generic  architectures,  and  domain  specific  languages  (80).  In 
this  mechanism,  a  domain  model  is  captured  via  definition  of  the  basic  objects,  operations,  and 
communication  paths  in  the  domain.  Object-oriented  constructs  such  as  inheritance  and  aggre- 
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Figure  2.2  Parallel  Refinement  Specification  Acquisition  Mechanism 


gation  are  used  to  model  generalization  and  specialization  of  domain  objects  as  well  as  how  they 
are  composed  into  other  domain  objects.  The  domain  model  thus  defines  a  language  from  which 
systems  are  specified.  A  functional  specification  is  developed  by  refining  a  domain  model  through 
selection  of  applicable  domain  objects,  instantiation  of  domain  object  parameters,  and  definition  of 
specific  communications  paths  between  system  objects.  Once  the  system  function  is  fully  specified, 
the  system  specification  is  completed  by  determining  how  to  decompose  the  system  into  separate 
processes  and  how  those  processes  communicate. 

Domain  models  are  created  by  domain  engineers  using  knowledge  from  domain  experts  and 
stored  in  the  Theory  Library.  Domain  models  consist  of  a  set  of  class  theories,  which  describe 
the  objects,  operations,  and  communications  paths  of  a  domain.  Individual  class  theories  may 
describe  the  attributes,  methods,  states,  and  events  of  a  group  of  similar  objects  in  a  domain  or 
the  relationships  and  communication  paths  between  objects. 
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Class  theories  from  a  given  domain  are  refined  by  users  and  system  analysts  to  create  func¬ 
tional  specifications  which  are  also  stored  in  the  Theory  Library.  Functional  specifications  have  the 
same  syntactic  form  eis  class  theories  but  are  tailored  toward  the  requirements  of  a  specific  problem. 
Intuitively,  functional  specifications  are  models  of  a  domain  class  theory. 

Architecture  theories  describe  the  structure  of  systems  in  terms  of  processes  and  inter-process 
communications  and  are  also  stored  in  the  Theory  Library.  Generally,  while  class  theories  are 
domain  specific,  architecture  theories  are  domain  independent-they  are  defined  solely  in  terms  of 
processes  and  inter-process  communication. 

Once  a  functional  specification  has  been  completed,  the  system  analyst  selects  (or  develops) 
a  corresponding  architecture  theory  from  the  theory  library.  The  architecture  theory’s  process  pa¬ 
rameters  are  then  instantiated  with  class  theories  from  the  functional  specification  to  form  a  system 
specification.  For  example,  the  system  analyst  may  instantiate  an  architecture  theory  with  three 
processes  running  in  parallel  with  refined  versions  of  a  propulsion  device  class  theory,  airframe  class 
theory,  and  a  fuel-tank  class  theory  from  a  rocket  system  domain  to  create  a  rocket  system  speci¬ 
fication.  In  essence,  a  system  specification  is  a  model  of  a  generic  architecture  theory  instantiated 
with  domain  specific  class  theories. 

Although  the  domain  engineer  or  system  analyst  is  producing  theory-based  models  and  spec¬ 
ifications,  interaction  with  the  system  is  through  a  conceptually  simpler  object-oriented  interface. 
Ideally,  this  interface  consists  of  a  graphical  user  interface  with  which  the  engineer  or  analyst 
specifies  domain  object  classes,  associations,  and  architectures  to  define  the  domain  or  architecture 
structure.  Object  attributes  and  operation  semantics  are  then  specified  algebraically  or  graphically. 
Structures  representing  behavior,  such  as  state  charts  and  data  flow  diagrams,  are  automatically 
translated  into  equivalent  algebraic  definitions. 

As  the  engineer  or  analyst  interacts  with  the  object-oriented  user  interface,  commands  and 
data  are  translated  to  the  theory-based  subsystems  where  the  actual  composition  occurs  and  proofs 
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of  consistency  and  correctness  are  performed.  For  example,  a  domain  engineer  may  create  a  new 
class  that  inherits  from  an  existing  class.  As  the  domain  engineer  creates  the  new  class,  attributes, 
and  methods,  the  Specification  Acquisition  Mechanism  carries  out  proof  obligations  to  show  that 
the  composition  specified  by  the  domain  engineer  satisfies  appropriate  composition  rules  defined 
by  the  theory-based  object  model  in  Chapter  VI. 

After  the  domain  engineer  creates  a  domain  model  and  proves  the  correctness  of  its  composi¬ 
tion,  a  system  analyst  uses  it  to  produce  a  functional  specification.  Again,  the  system  analyst  works 
with  an  object-oriented  representation  of  the  system  while  the  operations  and  proofs  are  carried  out 
on  the  theory-ba.sed  specification.  When  complete,  the  functional  specification  is  combined  with 
an  architecture  theory  to  define  a  theory-based  system  specification  which  is  fed  into  a  correctness 
preserving  Design  Refinement  Mechanism  which  derives  code  satisfying  the  specification.  Since  the 
domain  and  architecture  models  are  stored  in  the  Theory  Library,  maintenance  is  performed  by 
modifying  the  class  and  architecture  theories  and  re-deriving  the  system  specification  and  software. 

2.2  Domain  Engineering 

Domain  engineering  is  the  process  of  developing  domain  models  for  use  in  constructing  ap¬ 
plications  within  the  domain.  This  section  presents  a  basic  overview  of  domain  engineering  in 
Section  2.2.1  followed  by  how  the  Specification  Acquisition  Mechanism  proposed  in  this  research 
implements  domain  engineering  in  Section  2.2.2. 

2.2.1  Overview.  The  term  domain  analysis  was  first  used  by  Neighbors  to  describe  “the 
activity  of  identifying  the  objects  and  operations  of  a  class  of  similar  systems  in  a  particular  problem 
domain”  (78);  however,  since  that  time  the  definition  of  domain  analysis  has  been  expanded  and 
applied  to  more  than  just  identifying  objects  and  operations  in  a  given  domain.  The  size  of  a 
domain  may  vary  from  very  large  and  complex  to  very  simple.  The  domain  “avionics”  is  fairly 
large  and  complex  while  the  domain  “basic  logic  operators”  is  straight  forward  and  comparatively 
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small.  Most  domain  analysis  approaches  are  based  on  application  area  domains.  An  application 
area  domain  is  a  domain  where  the  applications  define  the  domain  (e.g.,  stack  packages,  basic  logic 
operators,  etc.)  (97).  This  is  the  definition  used  in  this  research.  While  many  definitions  abound 
((51,  9,  77,  79,  97)),  perhaps  the  simplest  and  most  straight-forward  definition  is  the  process  where 
“domain  knowledge  is  studied  and  formalized”  (96). 

The  goal  of  domain  analysis  is  to  capture  knowledge  in  order  to  reuse  it  in  developing  new 
systems.  After  the  domain  knowledge  is  gathered,  it  is  stored  in  a  domain  model  for  use  in  new 
software  development  efforts  to  increase  the  productivity  and  quality  of  new  systems.  As  such,  do¬ 
main  analysis  is  just  part  of  an  overall  process  called  domain  engineering  which  “includes  domain 
analysis  and  subsequent  construction  of  components,  methods,  and  tools  that  address  the  prob¬ 
lems  of  system/subsystem  development  through  the  application  of  domain  analysis  products”  (51). 
Domain  engineering  has  three  steps:  (1)  domain  analysis,  (2)  infrastructure  specification,  and  (3) 
infrastructure  implementation  (9).  (An  infrastructure  is  domain  knowledge  along  with  information 
on  how  to  find  and  use  that  knowledge). 

A  domain  model  is  used  to  represent  domain  knowledge  and  is  defined  as  the  “specific  rep¬ 
resentation  of  appropriate  aspects  of  an  application  domain”  (48).  A  domain  model  may  take 
on  various  forms  including  domain  taxonomies,  generic  architectures,  and  domain  specific  lan¬ 
guages  (80).  Domain  models  are  the  end  product  of  domain  analysis  and  contain  all  the  knowledge 
gathered  during  domain  analysis  including  software  architectures.  Software  architectures  consist  of 
“the  components,  connections,  constraints,  and  configurations  of  components  and  constraints  that 
specify  the  high-level  design  for  a  system”  (93).  Basically,  the  architecture  is  a  blueprint  for  com¬ 
posing  applications  given  well-defined  domain-specific  components.  Specification  of  generic  domain 
software  architectures  is  critical  to  the  automatic  generation  of  domain-specific  applications. 

2.2.2  Implementation.  As  shown  in  Figure  2.2,  domain  engineering  is  the  first  phase 
in  system  specification  acquisition  and  is  the  main  focus  of  this  research.  Domain  knowledge 
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is  input  through  an  object-oriented  user  interface,  translated  to  theory-based  specifications,  and 
stored  in  the  Theory  Library  by  the  Domain  Theory  Composition  Subsystem.  This  component 


translates  graphically  oriented  OMT  specifications,  augmented  with  first-order  logic  axioms,  into 
theory-based  class  theories.  A  particular  domain  analysis  methodology  is  not  specified  for  use  with 
the  subsystem;  however,  the  chosen  methodology  should  be  compatible  with  capturing  domain 
knowledge  in  an  object-oriented  setting. 

The  heart  of  the  translation  process  from  OMT  to  class  theories  is  a  Theory-Based  Object 
Model  as  defined  in  Chapter  VI.  This  model  defines  object-oriented  concepts  in  a  formal  framework 
based  on  algebraic  specifications  and  category  theory,  thus  providing  a  powerful  ability  to  reason 
about  the  resulting  specifications.  Due  to  the  undecidability  of  first-order  axiom  consistency,  axioms 
entered  into  the  subsystem  are  assumed  consistent;  however,  composition  rules  are  used  to  ensure 
inconsistencies  are  not  introduced  during  the  composition  process.  It  is  also  in  this  subsystem  that 
completeness  proofs  are  performed.  These  proofs  show  that  the  effect  of  each  operation  on  a  given 
object  is  completely  defined  by  the  domain  engineer. 

The  output  of  the  Domain  Theory  Composition  Subsystem  is  a  theory-based  domain  model. 
An  example  of  the  object-oriented  view  of  a  domain  model  for  a  simulated  rocket  is  shown  in 
Figure  2.3.  The  simulated  rocket  domain  consists  of  three  types  of  components:  airframes,  fuel 
tanks,  and  propulsion  devices.  Characteristics  of  all  airframes  and  propulsion  devices  are  defined  in 
the  Airframe  and  Propulsion  Device  classes.  Characteristics  of  particular  airframes  and  propulsion 
devices  are  defined  in  specializations  of  those  object  classes.  The  relationship  between  a  fuel  tank 
and  a  propulsion  device  is  defined  in  the  Feeds  association.  The  basic  structure  of  a  simulated 
rocket  object  is  described  by  the  aggregation  of,  and  multiplicities  defined  by  the  airframe,  fuel 
tank,  and  propulsion  device  components;  however,  this  structure  does  not  define  the  process-based 
architecture.  This  domain  model  is  refined  and  implemented  in  a  number  of  ways.  The  system 
analyst  may  define  the  system  as  a  single  process,  as  multiple  processes  (one  for  each  object  class). 
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or  any  combination  in  between.  These  decisions  are  made  during  the  specification  generation 


and  structuring  phases  described  below.  Only  the  functionality  of  basic  domain  objects  and  their 


specializations  are  defined  during  the  domain  engineering  phase, 
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Figure  2.3  Rocket  Object  Domain  Model 


2.3  Specification  Generation 

Specification  generation  transforms  domain  models  into  specifications  defining  the  functional¬ 
ity  of  a  particular  system  in  the  domain.  Functional  specifications  developed  through  the  Specifica¬ 
tion  Generation/Refinement  Subsystem  have  the  same  theory-based  syntax  as  the  domain  model’s 
class  theories.  The  basic  result  of  specification  generation  is  to  create  a  system  specification  based 
on  the  domain  model  and  then  to  restrict  the  number  of  models  satisfying  the  specification.  Specific 
generation/refinement  operations  include: 

1.  parameter  instantiation 
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2.  specialization  selection 

3.  multiplicity  restriction 

4.  initialization  definition 

5.  communication  path  definition 

6.  constraint  restriction 

Parameter  instantiation  is  the  selection  of  values  for  predefined  class  parameters.  These  pa¬ 
rameters  can  be  single  values  or  ranges  of  values.  In  either  case,  parameter  instantiation  results 
in  the  addition  of  axioms  to  the  class  definition  that  restrict  object  behavior.  Specialization  Selec¬ 
tion  allows  the  system  analyst  to  select  a  particular  class  specialization.  Because  a  domain  theory 
models  the  entire  application  domain,  it  includes  various  class  specializations  in  order  to  capture 
important  variations  in  structure  and  behavior.  Specialization  selection  simplifies  and  restricts 
the  system  specification  by  removing  unwanted  specializations.  Multiplicity  Restriction  allows  the 
system  analyst  to  explicitly  decide  how  many  objects  are  allowed  in  aggregates  and  associations. 
Often,  domain  engineers  define  few  restrictions  on  object  class  relationships  (i.e.,  they  allow  “zero 
or  more”  objects  in  any  given  relationship).  While  this  generalizes  the  domain  model,  actual  sys¬ 
tems  within  the  domain  are  more  restrictive.  Multiplicity  restriction  simplifies  the  specification  by 
placing  additional  constraints  on  aggregate  and  association  multiplicities.  Initialization  Definition 
allows  the  system  analyst  to  state  specifically  how  objects  are  initialized.  For  instance,  while  a 
domain  model  may  state  that  a  one-to-one  association  exists  between  two  classes,  initialization 
defintion  allows  the  system  analyst  to  specify  which  objects  from  the  two  classes  are  associated.  A 
similar  situation  exists  for  aggregates.  Often,  the  question  of  whether  an  aggregate  creates  its  com¬ 
ponents  upon  initialization  or  they  are  created  separately  is  left  unspecified  in  the  domain  model. 
Initialization  defintion  allows  the  system  specifier  to  specify  these  requirements.  Communication 
Path  Definition  allows  the  system  developer  to  specify  exactly  which  objects  require  communica¬ 
tion.  In  the  domain  model,  the  domain  engineer  is  concerned  with  specifying  the  classes  of  objects 
that  may  communicate,  not  which  specific  objects  actually  do  communicate.  In  many  cases,  even 
though  an  object  can  communicate  with  all  objects  in  a  given  class,  it  may  only  need  to  commu- 
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nicate  with  one  specific  object  from  that  class.  These  constraints  are  added  via  communication 
path  definition.  The  last  generation  operation,  constraint  restriction  is  a  generic  refinement  opera¬ 
tion.  Constraint  restriction  allows  the  system  analyst  to  place  further  constraints  on  class  behavior 
through  the  introduction  of  axioms.  These  axioms  are  used  to  place  restrictions  on  attributes  or 
define  restrictions  across  aggregate  components  or  associations. 

The  specialization  of  the  Rocket  Domain  Model,  shown  in  Figure  2.3,  to  the  Rocket  Object 
Model,  shown  in  Figure  2.4  is  a  simple  example  of  the  first  four  generation/refinement  operations. 
First,  the  system  analyst  selects  one  Jet  Engine  class  from  the  Jet  Engines  available  in  the  do¬ 
main  model.  After  selecting  a  Jet  Engine,  the  system  analyst  removes  all  other  Propulsion  Devices 
(jet  and  rocket  engines)  and  restricts  the  l-f  multiplicity  constraint  between  the  Rocket  and  the 
Propulsion  Device  to  be  exactly  two.  Because  the  system  being  designed  has  exactly  one  Fuel 
Tank  for  each  Jet  Engine,  the  system  analyst  must  also  restrict  the  multiplicity  constraint  between 
the  rocket  and  Fuel  Tanks  from  zero-or-more  (•)  to  exactly  two  and  restricts  the  Feed  association 
between  the  Fuel  Tank  and  Jet  Engine  to  one-to-one  instead  of  many-to-many.  The  system  ana¬ 
lyst  might  then  select  the  ♦  aggregation  symbol  (an  extension  to  Rumbaugh’s  OMT  notation)  to 
specify  that  the  rocket  object  creates  its  component  objects  upon  creation.  To  complete  the  Fuel 
Tank  specialization,  the  system  analyst  also  provides  Fuel  Tank  parameters.  Finally,  the  system 
analyst  selects  a  specialization  from  the  Airframe  class  and  completes  any  remaining  Rocket-level 
constraints  by  providing  bindings  for  any  Rocket  class  parameters. 

Further  system-level  functional  constraints  axe  captured  in  the  system  specification  through 
constraint  restriction.  Communication  path  definition  is  not  included  in  this  example  due  to  the 
complexity  of  inter-object  communication  (Section  6.6);  however,  if  a  Fuel  Tank  is  required  to 
communicate  with  its  Jet  Engine,  the  system  analyst  may  specify  that  the  Fuel  Tank  communicate 
only  with  the  Jet  Engine  to  which  it  is  associated  via  the  Feeds  association. 
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Figure  2.4  Specific  Rocket  Object  Model 
2-4  Specification  Structuring 

Specification  structuring  allows  the  system  analyst  to  define  the  structure  of  the  application 
in  terms  of  process  and  inter-process  communications.  This  phase  is  used  to  decompose  specifi¬ 
cations  into  simpler,  less  complex  specifications,  or,  to  build  up  larger  specifications  from  smaller 
specifications. 

An  Architecture  is  a  collection  of  objects  (in  this  case,  class  theories)  along  with  a  relation  over 
the  objects  defining  object  composition  (e.g.,  parallel,  sequential,  etc.).  Formally,  an  Architecture 
Theory  defines  a  collection  of  objects,  a  set  of  relations  over  those  objects  that  define  the  syntax 
of  object  composition,  and  a  collection  of  axioms  over  the  objects  and  relations  that  define  the 
semantics  of  the  architecture.  An  architecture  theory  consists  of  a  structuring  specification,  which 
describes  how  the  processes  are  composed  (e.g.,  sequential,  parallel,  etc.)  and  a  diagram  that 
specifies  how  to  construct  the  final  system  specification.  Thus  an  architecture  defines  the  objects 
of  interest  and  the  composition  rules  for  these  objects(32). 

In  the  Specification  Acquisition  Mechanism,  an  architecture  theory  is  a  parameterized  spec¬ 
ification  that  defines  the  structure  of  an  application  in  terms  of  processes  and  communication 
channels  between  the  processes.  The  parameters  of  the  architecture  theory  are  class  theories,  each 
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of  which  becomes  a  process  in  the  system.  The  architecture  theory  also  includes  a  diagram  defining 
exactly  how  the  architecture  theory  is  to  be  parameterized  and  how  the  final  system  specification 
is  composed.  For  example,  a  parallel  architecture  theory  is  defined  as  a  set  of  class  theories,  the 
parallel  process  composition  operator, 

_  II  _  :  process,  process  — >  process 

and  a  satisfaction  relation,  |=,  which  defines  the  relationship  between  class  specifications  and  their 
models  (32:6-3). 

The  Architecture  Matching  Subsystem  is  used  to  bind  architecture  theories  to  functional  spec¬ 
ifications.  The  system  analyst  selects  class  theories  from  the  functional  specification  and  matches 
them  to  processes  in  a  predefined  architecture  theory.  Each  class  theory  (or  group  of  class  theo¬ 
ries)  in  the  functional  specification  must  correspond  to  a  process  while  all  communication  between 
class  theories  or  class  theory  groups  must  correspond  to  a  communication  channel  in  the  selected 
architecture  theory.  This  is  an  example  of  an  imposed  architecture  (32:2-8).  In  this  research,  I  as¬ 
sume  the  existence  of  architecture  theories  and  the  ability  to  create  them  using  graphically  oriented 
techniques,  and  instead  focus  on  the  acquisition  of  class  theories  in  the  form  of  domain  models. 

2.5  Summary 

This  chapter  has  presented  an  overview  of  a  theory-based  specification  acquisition  system  set 
in  a  software  development  framework.  The  software  development  framework  uses  three  components 
to  synthesize  software:  (1)  a  Specification  Acquisition  Mechanism  to  help  develop  theory-based 
system  specifications,  (2)  a  Design  Refinement  Mechanism  which  uses  algorithmic,  architectural, 
and  data  structure  refinements  to  the  system  specification  to  produce  an  implementation  in  an 
abstract  target  language,  and  (3)  a  Generation  &  Optimization  Mechanism  which  converts  the 
abstract  program  into  an  optimized  program  in  a  compilable  target  language. 
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The  Specification  Acquisition  Mechanism  is  used  to  develop  large-scale  theory-based  system 
specifications.  First,  a  domain  engineer  develops  a  domain  model  using  an  object-oriented  inter¬ 
face  to  the  Domain  Theory  Composition  Subsystem.  Then,  a  system  analyst  refines  the  domain 
model  into  a  functional  specification  by  removing  unneeded  domain  model  components  and  adding 
problem  specific  constraints.  Finally,  the  functional  specification  is  combined  with  an  architecture 
theory  to  produce  the  complete  theory-based  system  specification. 

The  presentation  of  the  proposed  Specification  Acquisition  System  in  this  chapter  has  been 
informal.  Subsequent  chapters  present  a  formal  definition  of  the  Domain  Theory  Composition 
Subsystem.  More  specifically,  the  remaining  chapters  define  a  mathematically  sound  foundation 
for  a  theory-based  model  of  object-orientation  and  the  translation  from  a  graphically  based  object- 
oriented  domain  model  to  a  theory-based  domain  model. 
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III.  Theories  and  Specifications 


3. 1  Introduction 

The  software  development  framework  presented  in  Chapter  II  is  predicated  on  the  use  of  for¬ 
mal,  mathematically-based  software  specifications.  There  are  two  types  of  specifications  commonly 
used  to  describe  behavior  in  a  formal  specification:  operational  and  definitional.  An  operational 
specification  is  basically  a  “recipe”  for  an  implementation  that  satisfies  the  specification  require¬ 
ments  while  a  definitional  specification  describes  behavior  by  listing  the  properties  that  an  imple¬ 
mentation  must  have  (43:5).  Definitional  specifications  have  several  advantages  over  operational 
specifications:  they  are  (1)  generally  shorter  and  clearer,  (2)  easier  to  modularize  and  combine 
together,  and  (3)  easier  to  reason  about.  This  last  advantage,  the  ability  to  reason  about  them,  is 
the  key  reason  they  are  used  in  automated  systems. 

It  is  generally  recognized  that  creating  correct,  understandable  formal  specifications  is  dif¬ 
ficult,  if  not  impossible,  without  the  use  of  some  structuring  technique  or  methodology  (33,  16). 
Algebraic  theories  provide  the  advantages  of  definitional  specifications  and  the  desired  structuring 
techniques.  Algebraic  theories  are  defined  in  terms  of  a  collection  of  values  called  sorts,  a  set  of 
operations  defined  over  the  sorts,  and  a  set  of  axioms  defining  the  semantics  of  the  sorts  and  opera¬ 
tions.  The  structuring  of  algebraic  theories  is  provided  by  category  theory  operations  and  provides 
an  elegant  way  in  which  to  combine  smaller  algebraic  theories  into  larger,  more  complex  theories. 

Categories  are  an  abstract  mathematical  construct  consisting  of  category  objects  and  category 
arrows.  In  general,  category  objects  are  the  objects  in  the  category  of  interest  while  category  arrows 
define  a  mapping  from  the  internal  structure  of  one  category  object  to  another.  In  this  research,  the 
category  objects  of  interest  are  algebraic  specifications  and  the  category  arrows  are  specification 
morphisms.  In  this  category.  Spec,  specification  morphisms  map  the  sorts  and  operations  of  one 
algebraic  specification  into  the  sorts  and  operations  of  a  second  algebraic  specification  such  that 
the  axioms  in  the  first  specification  are  theorems  in  the  second  specification.  Thus,  in  essence,  a 
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specification  morphism  defines  an  embedding  of  functionality  from  the  first  algebraic  specification 
in  the  second  specification. 


Use  of  algebraic  specification  for  specification  of  data  types  was  pioneered  in  the  mid  1970s 
by  Goguen  et  ah,  Liskov,  and  Zilles  (16,  66).  Extension  of  these  concepts  to  objects  and  object- 
orientation  was  initially  presented  by  Goguen  and  Meseguer  (38)  and  is  an  increasingly  common 
representation  technique  in  the  formalization  of  object-orientation  (7,  14,  65,  27,  69). 


3.2  Algebraic  Specification 


In  this  section,  I  define  the  important  aspects  of  algebraic  specifications  and  how  to  combine 
them  using  category  theory  operations  to  create  new,  more  complex  specifications.  As  described 
above,  category  theory  is  an  abstract  mathematical  theory  used  to  describe  the  external  structure 
of  various  mathematical  systems.  Before  showing  its  use  in  relation  to  algebraic  specifications,  I 
give  a  formal  defintion  (89). 

Definition  3.2.1  Category.  A  category  C  is  comprised  of 

1.  a  collection  of  things  called  C-objects; 

2.  a  collection  of  things  called  C-arrows; 

3.  operations  assigning  to  each  C -arrow  f  a  C -object  dom  f  (the  domain  of  f)  and  a  C -object 
cod  f  (the  “codomain”  of  f).  If  a  =  dom  f  and  b  =  cod  f  this  is  displayed  as 

f  :  a  -^b  or  a  b 

4-  an  operation,  “o”,  called  composition,  assigning  to  each  pair  {g,f)  of  C-arrows  with  dom  g 
=  cod  f ,  a  C -arrow  go  f  :domf  — >  cod  g,  the  composite  of  f  and  g  such  that  the  Associative 
Law  holds:  Given  the  configuration 

f  r  9  ^  J 

a  0  c—^  a 


of  C -objects  and  C-arrows,  then 


ho{gof)  =  {hog)of. 

5.  an  assignment  to  each  C-object,  b,  a  C-arrow,  id^  •.  b  b,  called  the  identity  arrow  on  b, 
such  that  the  Identity  Law  holds:  For  any  C-arrows  f  :  a  b  and  g  :b  c 
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idbof  -  f  and  goidb=  g. 


3.2.1  The  Category  of  Signatures.  In  algebraic  specifications,  the  structure  of  a  spec¬ 
ification  is  defined  in  terms  of  an  abstract  collection  of  values,  called  sorts,  and  operations  over 
those  sorts.  This  structure  is  called  a  signature  (88).  A  signature  describes  the  structure  that 
an  implementation  must  have  to  satisfy  the  associated  specification;  however,  a  signature  does  not 
specify  the  semantics  of  the  specification.  The  semantics  are  added  later  via  axiomatic  definitions. 


Definition  3.2.2  Signature.  A  signature  S  =  {S,Q),  consists  of  a  set  S  o/ sorts  and  a  set  fl 
of  operation  symbols  defined  over  S.  Associated  with  each  operation  symbol  is  a  sequence  of  sorts 
called  its  rank.  For  example,  f  :  si,S2,  ■ .  ■  ,Sn  s  indicates  that  f  is  the  name  of  an  n-ary  function, 
taking  arguments  of  sorts  si,S2,  ■  ■  ■  ,Sn  and  producing  a  result  of  sort  s.  A  nullary  operation  symbol, 
c  :  — >  s,  is  called  a  constant  of  sort  s. 

An  example  of  a  signature  is  shown  in  Figure  3.1.  In  the  signature  Ring  there  is  one  sort, 
ANY,  and  five  operations  defined  on  the  sort. 
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sorts  ANY 

operations 
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:  ANY  X  ANY 

^  ANY 

times 

;  ANY  X  ANY 

^  ANY 

inv 

:  ANY 

ANY 

zero 

-4  ANY 

one 

ANY 

end 

Figure  3.1 

Ring  Signature 

In  my  research,  a  signature  defines  the  structure  needed  to  describe  object  classes  (attributes 
and  operations)  in  a  formal  way.  Signatures  provide  the  ability  to  define  the  internal  structure 
of  a  specification;  however,  they  do  not  provide  a  method  to  reason  about  relationships  between 
specifications.  To  create  theory-based  algebraic  specifications  that  parallel  object-oriented  speci- 


3-3 


fications,  specification  refinements  on  theories  similar  to  those  used  in  object-oriented  approaches 
(inheritance,  aggregation,  etc.),  must  be  available.  There  must  be  a  well-defined  theory  about  how 
to  reason  about  the  external  structure  of  these  specifications  (i.e.,  how  they  relate  to  one  another). 

As  might  be  expected,  signatures  (as  the  “C-objects”)  with  the  correct  “C-arrows”  form  a 
category  which  is  of  great  interest  in  this  research.  For  signatures,  the  C-arrows  are  called  signature 
morphisms  (88).  Signatures  and  their  associated  signature  morphism  form  the  category.  Sign. 

Definition  3.2.3  Signature  Morphism.  Given  two  signatures  S  =  (5',  fi)  and  S'  =  {S',Q'), 
a  signature  morphism  a  :  T,  T,'  is  a  pair  of  functions  {as  :  5  — »  5",  an  :  Cl  0,'),  mapping 
sorts  to  sorts  and  operations  to  operations  such  that  the  sort  map  is  compatible  with  the  ranks 
of  the  operations,  i.e.,  for  all  operation  symbols  f  :  Si,S2,  ■  ■  ■  ,Sn  s  in  Cl,  the  operation  symbol 
o'nif)  '•  o'sisi),  as(s2),  ■■  ■ ,  as(sn)  — »  as(s)  is  in  Cl'.  The  composition  of  two  signature  morphisms, 
obtained  by  composing  the  functions  comprising  the  signature  morphisms,  is  also  a  signature  mor¬ 
phism.  The  identity  signature  morphism  on  a  signature  maps  each  sort  and  each  operation  onto 
itself.  Signatures  and  signature  morphisms  form  a  category.  Sign,  where  the  signatures  are  the 
C-objects  and  the  signature  morphisms  are  the  C-arrows. 

Given  the  signature  Ring  (Figure  3.1)  and  RingInt  (Figure  3.2),  a  signature  morphism 
(7  :Ring^RingInt,  is  shown  in  Figure  3.3.  As  required  by  Definition  3.2.3,  a  consists  of  two 
functions,  as  and  an  as  shown,  as  maps  the  sort  ANY  to  Integer  while  an  maps  each  operation 
to  an  operation  with  a  compatible  rank. 

Signature  morphisms  map  sorts  and  operations  from  one  signature  into  another  and  allow 
the  restriction  of  sorts  as  well  as  the  restriction  of  the  domain  and  range  of  operations.  However, 
to  build  up  more  complex  signatures,  introduction  of  new  sorts  and  operations  into  a  signature  is 
required.  This  is  accomplished  via  a  signature  extension  (32). 
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spec  RingInt  is 

sorts  Integer 

operations 

-f  :  Integer  x  Integer 

Integer 

X  :  Integer  x  Integer 

Integer 

;  Integer 

— >  Integer 

0  : 

— >  Integer 

1  : 

Integer 

end 


Figure  3.2  Integer  Ring  Signature 
as  —  {ANY  i->  Integer} 

=  {plus  I-+  +,  times  x,  inv  i->  zero  0,  one  i->  1} 


Figure  3.3  Signature  Morphisms;  Ring  — >  RingInt 

Definition  3.2.4  Extension.  A  signature  S2  =  (52,02)  extends  a  signature  Si  =  (Si,Qi)  if 
Si  C  S2  and  0i  C  02- 

Signature  morphisms  are  used  to  rename  and  refine  sorts  and  to  restrict  the  domain  and 
range  of  operations,  while  extensions  are  used  to  add  new  sorts  and  operations  to  signatures.  These 
operations  allow  the  definition  of  entirely  new  signatures  and  the  growth  of  complex  signatures  from 
existing  signatures. 


3.2.2  The  Category  of  Specifications.  The  basic  definitions  required  to  develop  the  cate¬ 
gory  of  signatures  and  signature  morphisms  were  presented  in  Section  3.2.1;  however,  the  semantics 
required  for  software  specifications  have  yet  to  be  introduced.  To  model  these  semantics,  the  defi¬ 
nition  of  a  signature  is  extended  with  axioms  which  define  the  intended  semantics  of  the  signature 
operations.  A  signature  with  associated  axioms  is  called  a  specification  (88). 


Definition  3.2.5  Specification.  A  specification  SP  is  a  pair  (E,$)  consisting  of  a  signature 
S  =  {S,Cl)  and  a  collection  $  of  'E-sentences  (axioms). 
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Although  a  specification  includes  semantics,  it  does  not  implement  a  program  nor  does  it 
define  a  particular  implementation.  A  specification  only  defines  the  semantics  required  of  a  valid 
implementation.  In  fact,  for  most  specifications,  there  are  a  number  of  implementations  that  satisfy 
the  specification.  Implementations  that  satisfy  all  axioms  of  a  specification  are  called  models  of  the 
specification  (88).  To  formally  define  a  model,  I  first  define  a  S-algebra  (88). 

Definition  3.2.6  S-algebra  or  S-model.  Given  a  signature  S  =  {S,Cl),  a  T,-algebra  A  = 
{As,  Fa)  consists  of  two  families: 

1.  a  collection  of  sets,  called  the  carriers  of  the  algebra,  As  —  {Ag  |  s  6  S'};  and 

2.  a  collection  of  total  functions.  Fa  =  {fA  \  f  ^  such  that  if  the  rank  of  f  is  si,S2,  ■  ■ .  ,Sn 

s,  then  fA  is  a  function  from  Ag^  xAg^  x  -  •  •xA«„  to  Ag.  The  symbol  x  indicates  the  Cartesian 
product  of  sets  here. 


Definition  3.2.7  Model.  A  model  of  a  specification  SP  =  (S,  $)  is  a  H-algebra,  M,  such  that  M 
satisfies  each  Y,-sentence  (axiom)  in  $.  The  collection  of  all  such  models  M  is  denoted  by  ModfSP]. 
The  sub-category  o/Mod(S}  induced  by  ModfSP]  is  also  denoted  by  ModfSP]. 


spec  Ring 

is 

sorts  ANY 

operations 

plus  : 

ANY  X  ANY 

ANY 

times  : 

ANY  X  ANY 

^  ANY 

inv  : 

ANY 

-V  ANY 

zero  : 

^  ANY 

one  : 

ANY 

axioms 

'ia,b,c&ANY 

a  plus  {b  plus  c)  (a  plus  b)  plus  c 

a  plus  b  =  b  plus  a 

a  plus  zero  =  a 

a  plus  (inv  a)  =  zero 

a  times  {b  times  c)  =  (a  times  b)  times  c 

a  times  one  —  a 

one  times  a  =  a 

a  times  (b  plus  c)  =  (a  times  b)  plus  {a  times  c) 
{a  plus  b)  times  c  =  {a  times  c)  plus  {b  times  c) 

end 


Figure  3.4  Ring  Specification 


3-6 


An  example  of  a  specification  is  shown  in  Figure  3.4.  This  specification  is  the  original  Ring 
signature  of  Figure  3.1  enhanced  with  the  axioms  that  define  the  semantics  of  the  operations.  Valid 
models  of  this  specification  include  the  set  of  all  integers,  Z,  with  addition  and  multiplication  as 
well  as  the  set  of  integers  modulo  2,  Zj  =  {0, 1},  with  the  inverse  operation  (-)  defined  to  be  the 
identity  operation. 

As  signatures  have  signature  morphisms,  specifications  have  specification  morphisms.  Speci¬ 
fication  morphisms  are  signature  morphisms  that  ensure  that  the  axioms  in  the  source  specification 
are  theorems  (are  provable  from  the  axioms)  in  the  target  specification.  Showing  that  the  axioms 
of  the  source  specification  are  theorems  in  the  target  specification  is  a  proof  obligation  that  must 
be  shown  for  each  specification  morphism.  Specifications  and  specification  morphisms  enable  the 
creation  and  modification  of  specifications  that  correspond  to  valid  signatures  within  the  category 
Sign.  Before  formally  defining  specification  morphism,  I  must  first  define  a  reduct  (88). 

Definition  3.2.8  Reduct.  Given  a  signature  morphism  cr  :  S  -+  S'  and  a  H'-algehra  A' ,  the 
a-reduct  of  A! ,  denoted  A!  \„,  is  the  Tf-algebra  A  =  {As,  Fa)  defined  as  follows  (with  S  =  {S,Cl)): 

"^5  =  for  s  e  S,  and  for  fA  =  {(r{f))A' ,  for  f  &  n 

A  reduct  defines  a  new  S-algebra  (or  S-model)  from  an  existing  S'-algebra.  It  accomplishes 
this  by  selecting  a  set  or  function  for  each  sort  or  operation  in  S  based  on  the  signature  morphism 
from  S  to  S'.  Thus  if  we  have  a  signature.  S',  and  a  S'-model,  we  can  create  a  S-model  for  a 
second  signature,  S,  by  defining  a  signature  morphism  between  them  and  taking  the  reduct  based 
on  that  signature  morphism.  A  reduct  is  now  used  to  extend  the  concept  of  a  signature  morphism 
to  form  a  specification  morphism  (88). 

Definition  3.2.9  Specification  Morphism.  A  specification  morphism  from  a  specification 
SP  =  (S,$)  to  a  specification  SF  =  (S',$')  is  a  signature  morphism  cr  :  S  — >  S'  such  that  for 
every  model  M  e  ModfSPJ,  M\cr£  ModfSPJ.  The  specification  morphism  is  also  denoted  by  the 
same  symbol,  cr  :  S  — >  S'. 


3-7 


I  now  turn  to  the  definition  of  theories  and  theory  presentations.  Basically  a  theory  is  the 
set  of  all  theorems  that  logically  follow  from  a  given  set  of  axioms  (89).  A  theory  presentation  is  a 
specification  whose  axioms  are  sufficient  to  prove  all  the  theorems  in  a  desired  theory  but  nothing 
more.  Put  succinctly,  a  theory  presentation  is  a  finite  representation  of  a  possibly  infinite  theory. 
To  formally  define  a  theory  and  theory  presentation  I  must  first  define  logical  consequence  and 
closure  (89). 

Definition  3.2.10  Logical  Consequence.  Given  a  signature  E,  a  Y,-sentence  ip  is  said  to  be  a 
logical  consequence  of  the  T,-sentences  ipi,. ipn,  written  <pi,...  ,tpn  \=  if  each  Ti-algebra  that 
satisfies  the  sentences  (pi,.  ..,pn  o,lso  satisfies  ip. 

Definition  3.2.11  Closure,  Closed.  Given  a  signature  S,  the  closure  ^  of  a  set  of  Ti-sentences 
$  is  the  set  of  all  Ti-sentences  which  are  the  logical  consequence  o/$,  i.e.,  $  =  {cp  |  $  |=  p).  A  set 
of  'S-sentences  $  is  said  to  be  closed  if  and  only  i/#  =  $. 

Definition  3.2.12  Theory,  presentation.  A  theory  T  is  a  pair  (S,  #)  consisting  of  a  signature 
S  and  a  closed  set  ofH-sentences,  $.  A  specification  (E,  $)  is  said  to  be  a  presentation  for  a  theory 
(E,#).  A  model  of  a  theory  is  defined  just  as  for  specifications;  the  collection  of  all  models  of  a 
theory  T  is  denoted  Mod[T].  Theory  morphisms  are  defined  analogous  to  specification  morphisms. 

Specification  morphisms  complete  the  basic  toolset  required  for  defining  and  refining  speci¬ 
fications.  This  toolset  can  now  be  extended  to  allow  the  combination,  or  composition,  of  existing 
specifications  to  create  new  specifications.  Often  two  specifications  that  were  originally  extensions 
from  the  same  ancestor  need  to  be  combined.  Therefore,  the  desired  combined  specification  consists 
of  the  unique  parts  of  two  specifications  and  some  “shared  part”  that  is  common  to  both  specifica¬ 
tions  (the  part  defined  in  the  shared  ancestor  specification).  This  combining  operation  is  called  a 
colimit  (89).  The  colimit  operation  creates  a  new  specification  from  a  set  of  existing  specifications. 
This  new  specification  has  all  the  sorts  and  operations  of  the  original  set  of  specifications  without 
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duplicating  the  “shared”  sorts  and  operators.  To  formally  define  a  colimit,  I  must  first  define  a 
cone  (89). 


Definition  3.2.13  Cone.  Given  a  diagram  D  in  a  category  C  and  a  C-object  c,  a  cone  from  the 
vertex  c  to  the  base  D  is  a  collection  of  C-arrows  {/j  :  c  — >  dj  |  dj  €  D},  one  for  each  object  di  in 
the  diagram  D,  such  that  for  any  arrow  g  :  di-^dj  in  D,  the  diagram  shown  in  Figure  3.5  commutes 
i.e.,  gofi  =  fj. 


C 


Figure  3.5  Cone  Diagram 


Definition  3.2.14  Colimit.  A  colimit  for  a  diagram  D  in  a  category  C  is  a  C-object  c  along  with 
a  cone  {fi  :  di  —y  c  \  di  €  D}  from  D  to  c  such  that  for  any  other  cone  {/•  :  d,  — »  c'  |  dj  G  D} 
from  D  to  a  vertex  c',  there  is  a  unique  C-arrow  f  :  c—y  d  such  that  for  every  object  di  in  D,  the 
diagram  shown  in  Figure  3.6  commutes;  i.e.,  f  o  fi  =  //. 


Figure  3.6  Colimit  Diagram 


Conceptually,  the  colimit  of  a  set  of  specifications  is  the  “shared  union”  of  those  specifications 
based  on  the  morphisms  between  the  specifications.  These  morphisms  define  equivalence  classes  of 
sorts  and  operations.  For  example,  if  a  morphism  for  specification  A  to  specification  B  maps  sort 
a  to  sort  then  a  and  ^  are  in  the  same  equivalence  class  and  thus  is  a  single  sort  in  the  colimit 
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specification  of  A,  B,  and  the  morphism  between  them.  Therefore,  the  colimit  operation  creates 
a  new  specification,  the  colimit  specification,  and  a  cocone  morphism  from  each  specification  to 
the  colimit  specification.  These  cocone  morphisms  satisfy  the  condition  that  the  translation  of  any 
sort  or  operation  along  any  set  of  morphisms  in  the  diagram  leading  to  the  colimit  specification 
are  equivalent  (54:23).  An  example  of  the  colimit  operation  is  shown  in  Figures  3.7  and  3.8.  Given 
the  Bin-Rel,  Reflexive,  and  Transitive  specifications  in  Figure  3.7,  the  “colimit  specification” 
would  be  the  Pre-Order  specification  as  shown  in  the  diagram  in  Figure  3.8.  Notice  that  the 
sorts  E,  X,  and  T  belong  to  the  same  equivalence  class  in  Pre-Order.  Likewise,  the  operations  •, 
=,  and  <  also  form  an  equivalence  class  in  Pre-Order.  Thus  Pre-Order  defines  a  specification 
with  one  sort,  {E,  X,  T}  and  one  operation,  {*,  =,  <},  which  is  both  transitive  and  reflexive. 
The  specification  Bin-Rel  defines  the  “shared”  parts  of  the  colimit  but  adds  nothing  to  the  final 
specification. 

A  category  in  which  the  colimit  of  all  possible  C-objects  and  C-arrows  exists  is  called  co¬ 
complete.  As  shown  by  Goguen  and  Burstall  (33,  34),  the  category  Sign  and  Spec  are  both 
cocomplete;  therefore,  the  colimit  operation  may  be  used  freely  within  the  category  Spec  to  define 
the  construction  of  complex  theories  from  a  group  of  simpler  theories. 

Using  morphisms,  extensions,  and  colimits  as  a  basic  toolset,  there  are  a  number  of  ways  that 
specifications  can  be  constructed:  (88,  37) 

•  Build  a  specification  from  a  signature  and  a  set  of  axioms; 

•  Form  the  union  of  a  collection  of  specifications; 

•  Translate  a  specification  via  a  signature  morphism; 

•  Hide  some  details  of  a  specification  while  preserving  its  models; 

•  Constrain  the  models  of  a  specification  to  be  minimal; 

•  Parameterize  a  specification;  and 

•  Implement  a  specification  using  features  provided  by  others. 

Many  of  these  methods  are  useful  in  translating  object-oriented  specification  development  into 
theory-based  specification  development.  For  instance,  object-oriented  inheritance  looks  very  similar 
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spec  Bin-Rel  is 
sorts  E 
operations 

•  :  E,  E  — ►  Boolean 

end 


spec  Reflexive  is 
sorts  X 
operations 

=  :  X,  X  — >  Boolean 

axioms 

\/x£X 

X  =  X 

end 


spec  Transitive  is 
sorts  T 
operations 

<  ;  T,  T  — >  Boolean 

axioms 

'ix,y,ze  T 

{x<yAy<z)=^x<z 

end 


spec  Pre-Order  is 
sorts  {E,  X,  T} 
operations 

{•,=,<}  :  {E,  X,  T},  {E,  X,  T}  ^  Boolean 
eixioms 

'ix,y,z£  {E,X,T} 

^  {•-=.<}  ^ 

{x  {•,  =,  <}  j/  A  y  {•,  =,  <}z)  X  {•,  =,  <}  z 

end 


Figure  3.7  Specification  Colimit  Example 


Figure  3.8  Example  Colimit  Diagram 
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to  an  extension  to  a  colimit  specification  where  the  diagram  of  the  colimit  specification  consists 
of  the  superclasses  of  the  target  specification.  Detailed  formal  semantics  of  these  object-oriented 
specification  refinement  concepts  is  discussed  in  Chapter  IV. 


3.3  Functors 

Sections  3.2.1  and  3.2.2  defined  the  basic  categories  and  construction  techniques  used  to 
build  large-scale  software  specifications.  In  this  section,  I  extend  these  concepts  further  to  define 
models  of  specifications  and  how  they  are  related  to  the  construction  techniques  used  to  create 
their  specifications.  Before  describing  this  relationship,  I  define  the  concept  of  a  functor  which 
maps  c-Objects  and  c-Arrows  from  one  category  to  another  in  such  a  way  that  the  identity  and 
composition  properties  are  preserved  (71). 

Definition  3.3.1  Given  two  categories  A  and  B,  a  functor  :  A  — »■  B  is  a  pair  of  functions,  an 
object  function  and  a  mapping  function.  The  object  function  assigns  to  each  object  X  of  category 
A  an  object  T{X)  o/B;  the  mapping  function  assigns  to  each  arrow  f  :  X  -*Y  of  category  A  an 
arrow  J(/)  :  5'(A)  — >  ?'(y)  of  category  B.  These  functions  satisfy  the  two  requirements: 


S^(lx)  =  for  each  identity  la,  of  A 

^{9  °  f)  =  ^{9)  °  ^{f)  foT  each  composite  go  f  defined  in  A 


(3.1) 


Basically  a  functor  is  a  morphism  of  categories.  Actually,  I  have  already  presented  two 
functors  in  Section  3.2.2:  the  reduct  functor  that  maps  models  of  one  specification  (in  the  category 
Mod[Xi])  into  models  of  a  second  specification  (in  the  category  Mod[A2])  and  the  models  functor 
that  maps  specifications  in  the  category  Spec  to  their  category  of  models,  ModjX],  in  Cat,  the 
category  of  all  sufficiently  small  categories.  An  example  of  the  use  of  the  reduct  and  models  functors 
is  given  in  Chapter  IV. 
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3-4  Summary 


This  chapter  presented  the  basic  mathematical  structure  upon  which  the  theoretical  foun¬ 
dations  of  a  theory-based  object  model  is  based.  The  chapter  started  by  presenting  the  abstract 
mathematical  concept  of  a  category,  which  is  a  set  of  c-Objects  and  a  set  of  c- Arrows  with  specific 
properties.  Then  a  signature  was  introduced  and  defined  to  be  comprised  of  a  set  of  sorts  and  a 
set  of  operations  over  those  sorts.  When  combined  with  signature  morphisms,  signatures  form  the 
category  of  Sign.  The  signatures  and  the  category  Sign  were  then  extended  to  specifications  and 
the  category  Spec  by  including  axioms  to  define  the  signature  semantics.  S-algebras,  or  models, 
were  then  introduced  and  defined  as  a  set  of  functions  and  sets  that  implement  the  semantics  of 
a  given  specification.  Finally,  functors  were  formally  defined  and  two  examples  given:  the  models 
functor  that  creates  models  of  a  specification  and  the  reduct  functor  that  creates  models  of  one 
specification  from  models  of  another  specification. 

The  mathematical  foundations  laid  in  this  chapter  are  used  in  the  remaining  chapters  to 
formally  define  object-oriented  concepts.  Specifically,  the  next  two  chapters  use  the  elements  in¬ 
troduced  in  this  chapter  to  define  some  basic  properties  of  formally  composed  theory-based  object- 
oriented  systems  as  well  as  domain  model  composition  techniques. 
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IV.  Theoretical  Foundations 

4.1  Introduction 

This  chapter  discusses  the  theoretical  foundations  for  a  theory-based  model  of  object- 
orientation.  To  date,  the  informal  definitions  of  objects,  classes,  and  inheritance  have  not  been 
agreed  on  much  less  their  formal  definitions.  This  chapter  formally  defines  basic  object-oriented 
concepts  such  as  objects,  classes,  and  inheritance  using  algebraic  specifications  in  a  category  the¬ 
ory  setting.  Algebraic  specifications  capture  the  internal  structure  and  semantics  of  the  individual 
classes  while  category  theory  operations  define  the  relationships  between  class  specifications.  This 
chapter  presents  a  general  theoretical  setting  in  order  to  remain  applicable  to  many  views  of  object 
orientation. 

Section  4.2  formally  defines  object  classes  as  theory  presentations  and  discusses  the  definition 
and  implications  of  internal  class  consistency.  Section  4.3  defines  the  category  theory  setting  for 
class  theories,  models  of  class  theories,  and  object  instances.  Finally,  Section  4.4  formally  defines 
inheritance  based  on  a  generally  accepted  notion  of  object-oriented  inheritance  and  extends  that 
definition  to  multiple  inheritance. 

4-2  Classes 

The  building  block  of  object-orientation  is  the  concept  of  an  object  class.  A  class  is  the 
blueprint  from  which  instances  of  the  class,  called  objects,  are  created.  There  are  two  notions  of  a 
class:  a  class  type  and  a  class  set.  A  class  type  defines  the  structure  of  a  group  of  similar  objects 
as  well  as  their  response  to  external  stimuli.  A  class  type  is  generally  defined  by  two  components: 
attributes  and  operations.  Attributes  are  observable  characteristics  of  objects  and  may  vary  over 
the  life  of  the  object.  Although  an  object’s  attribute  values  are  generally  visible  to  other  objects, 
modification  of  those  attribute  values  may  only  be  performed  by  the  object  itself.  Attribute  value 
modification  is  usually  performed  in  response  to  some  external  stimulus,  usually  in  the  form  of  a 
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message  or  event  being  received  by  the  object.  Receipt  of  a  message  or  event  causes  an  operation  to 
occur  which  in  turn  may  modify  the  object’s  attribute  values  or  cause  additional  messages  or  events 
to  be  generated.  Thus  a  class  type  defines  a  set  of  operations  which  are  used  to  view  attribute 
values  as  well  as  respond  to  messages  or  events.  These  operations  define  the  external  interface  of 
all  objects  in  the  class.  All  objects  that  conform  to  the  class  type  definition  are  in  the  class  set. 

Given  the  fact  that  class  types  define  a  set  of  operations  over  a  similar  collection  of  objects, 
class  type  definitions  may  be  modelled  naturally  as  specifications,  or  theory  presentations.  Sorts 
are  used  to  describe  collections  of  data  values  used  in  the  specification  and  include  a  distinguished 
sort,  the  class  sort.  The  class  sort  is  the  set  of  all  possible  object  names  in  the  class  and  provides 
a  reference  to  specific  objects  within  a  system.  However,  individual  objects  are  not  explicitly 
represented  in  specifications  —  specifications  only  define  the  structure  and  behavior  of  objects  in 
the  class.  Objects  themselves  are  implementation  artifacts  and  are  discussed  in  detail  in  Section 
4.3.1.  Attributes  are  defined  implicitly  by  operations  which  return  specific  data  values  associated 
with  a  given  object.  The  semantics  of  operations,  as  well  as  invariants  between  class  attribute 
values,  are  defined  using  first  order  predicate  logic  axioms.  In  general,  axioms  define  operations  by 
describing  their  effects  on  attribute  values  or  by  composing  other  operations.  I  now  formally  define 
a  class  type. 

Definition  4.2.1  Object  Class  Type  -  A  class  type,  C,  is  a  signature,  E  =  (S',  fl)  and  a  set  of 

axioms,  $,  over  E  (i.e.,  a  theory  presentation,  or  specification)  where 

S  denotes  a  set  of  sorts  including  the  class  sort 
n  denotes  a  set  of  operations  over  S 
$  denotes  a  set  of  axioms  over  E 

A  basic  assumption  for  a  class  C,  is  that  the  effect  of  each  operation  in  fl  is  completely 
defined  over  its  domain  by  $.  That  is,  each  function,  /  ;  A  — >  H  in  fl,  is  required  to  have  a 
provably  functional  relation  between  A  and  B.  This  requirement  is  not  as  restrictive  as  it  initially 
appears.  If  the  result  of  an  operation  does  not  make  sense  in  a  given  object  state  (i.e.,  divide  by 
zero,  etc.),  the  effect  of  the  operation  can  still  be  defined.  In  most  cases,  if  an  object  is  in  an 
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inappropriate  state  prior  to  operation  invocation  or  the  operation  parameters  are  invalid,  there  is 
no  change  in  the  object.  This  behavior  is  axiomatized  via  appropriate  preconditions.  For  example, 
given  an  integer  object  with  a  divide  operation  that  divides  the  integer  by  a  supplied  parameter, 
the  divide  operation  only  makes  sense  when  the  parameter  is  non-zero.  Thus  axioms  describing  the 
desired  behavior  are: 

parameter  7^  0  value(divide(integer, parameter))  =  integer  /  parameter 

parameter  =  0  =>•  value(divide(integer, parameter))  =  integer 

The  assumption  that  all  operations  are  completely  defined  over  their  domain  is  critical  in  defining 

the  effects  of  inheritance  in  Section  4.4. 

4-2.1  Internal  Class  Consistency.  It  is  impossible  to  show  that  a  given  class  type  is 
correctly  defined  without  the  existence  of  formal  requirements  documents.  Since  class  type  definition 
is  based  on  operations  and  axioms  defined  by  imperfect  humans,  the  best  that  can  be  achieved  is  to 
show  the  class  type  definition  is  internally  consistent;  however,  Church  and  Turing  independently 
showed  that,  in  general,  proving  that  a  set  of  first  order  equations  is  inconsistent  is  not  possible 
(18:45).  Therefore,  in  this  research,  I  assume  that  user  provided  specifications  are  consistent  and 
only  attempt  to  show  that  further  specification  composition  operations  (inheritance,  aggregation, 
etc.)  maintain  that  consistency. 

Lano  and  Haughton  present  three  conditions  for  internal  class  consistency. 

1.  3  (c  €  C)  I  INVc{c) 

2.  V  (c  G  C,  o  e  operaiions{C))  Preclp)  A  INVo(,c)  =>■  3  (c'  €  C)  |  o(c)  =  c  A  Invc{c) 

3.  V  (c,  c  €C,o  £  operations{C))  Precip)  A  INVc{c)  A  c'  =  o(c)  =4-  Invc{c)  (4.1) 

where  INVc{x)  are  the  invariant  constraints  of  a  class  C  applied  to  an  object  x,  operations{C)  are 
the  operations  declared  in  the  class  C,  and  Prec{o)  are  the  explicit  preconditions  of  the  operation 
o  as  defined  in  the  class  C. 

The  first  condition  states  that  a  model  of  the  class  type  must  exist.  Specifications  are  not 
necessarily  implementable.  I  can  easily  declare  inconsistent  axioms  as  shown  below. 
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x<0=^x  =  x+  l 
X  =  X  -  1 

Assuming  the  normal  semantics  of  +  and  —  over  a  total  order,  no  model  exists  where  x  =  x  —  1 
and  X  =  a:  +  1  are  both  true  simultaneously.  Therefore,  by  assuming  internal  class  consistency,  I 
also  assume  that  models  exist  for  all  user  provided  specifications.  This  assumption  is  important  in 
the  discussion  of  Section  4.3. 

The  second  condition  requires  that  the  preconditions  defined  for  each  operation  are  stronger 
than  the  preconditions  necessary  for  the  operation  to  work  correctly  while  the  last  condition  ensures 
that  all  operations  preserve  the  class  invariant  (i.e.,  applying  an  operation  to  an  object  in  a  valid 
state  results  in  an  object  in  a  valid  state).  Actually,  this  last  condition  is  redundant  since  the  second 
condition  requires  that  given  a  valid  object,  an  operation  must  result  in  a  valid  object.  Therefore, 
conditions  one  and  two  provide  a  complete  definition  of  internal  class  consistency. 

For  example,  if  the  divide  operation  is  defined  by 

divide{x,y)  =  x/y 

internal  consistency  is  violated.  The  axiom  defines  no  precondition;  however,  the  operation  in¬ 
vocation  divide{l,0),  results  in  an  invalid  state  since  1/0  is  undefined.  The  correct  definition  of 
divide  requires  an  appropriately  strong  precondition.  Internal  consistency  does  allow  the  explicit 
precondition  to  be  stronger  than  the  actual  condition.  Again,  if  the  divide  definition  was  rewritten 
as 

y  >  0  =>  divide(x,y)  =  x  /  y 
y  <  0  divide(x,y)  =  x 

internal  consistency  is  maintained  even  though  the  explicit  precondition,  y  >  0,  is  stronger  than 
the  required  precondition,  y  ^  0. 

4-3  Categorical  Setting 

Figure  4.1  shows  the  category  theory  setting  for  the  definition  of  classes  and  objects.  C  and  D 
represent  class  types  defined  within  the  category  Spec  with  a  specification  morphism,  a  :  C  —y  D. 


4-4 


Mod;Spec  ►  Cat 


The  specification  morphism  cr :  C  D  induces  a  reduct  functor,  denoted  D  \„,  from  Mod[D] 
to  Mod[C]  defined  as 

Vs  e  S,  Cs  =  and 
V/  fc=  o-CDd 
where 

C={S,n)  with 

Cs  is  a  set  from  of  model  in  Mod[C],  and 

fc  is  a  function  from  that  same  model  in  Mod[C]. 

Therefore,  if  class  type  compatibility  is  required  between  C  and  D,  as  implied  by  a,  compatible 
models  of  C  and  D  may  be  obtained  by  constructing  a  model  of  C  from  a  model  of  D  using  the 
reduct  functor.  (Here,  class  type  compatibility  means  that  if  C  and  D  have  common  sorts  and 
operations  as  defined  by  a,  their  models  must  have  common  sets  and  functions.)  Example  4.3.1 
illustrates  the  effects  of  the  reduct  functor  on  models  of  C  and  D. 


Figure  4.1  Object  Reduct  Framework 


The  model  functor  Mod:  Spec  — >  Cat  maps  each  specification  in  Spec  to  a  category  of  models 
in  Cat  (where  Cat  is  the  category  of  all  sufficiently  small  categories).  Thus  given  the  class  type 
D,  Mod[D],  represents  the  category  of  all  models  of  the  class  type  specification  D.  As  discussed 
in  Section  4.2.1,  because  I  assume  that  specifications  are  internally  consistent,  valid  models  of  each 
specification  exist.  An  implementation  of  a  class  type  D  is  defined  as  some  model  m  €  Mod[D]. 
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Example  4.3.1  Let  C  and  D  be  class  types  as  defined  in  Figure  4-2  where  the  notation  T>ca  <  Cca 
denotes  that  the  class  sort  of  V  is  a  subsort  of  the  class  sort  of  C  (i.e.,  D^s  Q  Cca)-  Then,  let 
Cmod  and  Dmod  represent  particular  models  ofC  and  D  in  the  categories  Mod/Cy  and  M.od[D]. 
As  shown  in  Figure  4-3,  Dmod  consists  of  four  sets  (Si  for  Cca,  S2  for  Vca,  S3  for  sort  A,  and  S4 
for  sort  B)  and  four  functions  (fi  for  a,  f2  for  /s  for  mi,  and  fi  for  m2)- 

The  reduct  functor  Dmod  \a  defines  the  model  Cmod  from  the  model  Dmod  by  selecting  those 
sets  and  functions  from  Dmod  that  correspond  to  sorts  and  operations  that  exist  in  both  C  and  V 
as  defined  by  the  morphism  a.  Therefore,  if  Dmod  consists  of  the  four  sets  and  four  functions 
described  above,  Cmod  consists  of  two  sets  (Si  for  Cca  ond  S3  for  sort  A,  and  two  functions  (fi 
for  a  and  /a  for  mi)  as  shown  in  Figure  4-4- 

class  C  is 
class  sort  Cca 
sorts  A 
attributes 
Oi  *  Cca  ^  -A- 
operations 

m-i  I  Cca,  ^  ^  Cca 

axioms 

axioms  omitted 
end-class 


class  V  is 

class  sort  Vca  <  Cca 
sorts  A,  B 
attributes 
U  *  Cca  ^  A 
/3  :  Vca  B 
operations 

m-i  ;  Cca,  A  ►  Cca 
m2  •  'Vca,  B  ^  Vca 
eixioms 

axioms  omitted 
end-class 


O'  =  {Cca  Cca,A^  A, a  a, mi  mi} 
Figure  4.2  Example  1  Class  Type  Definitions 
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4-3.1  Object  Instances.  As  discussed  earlier,  objects  are  not  explicitly  part  of  the  class 
type  specification  but  are  actually  implementation  artifacts.  Thus  objects  are  entities  that  behave 
according  to  a  given  implementation  of  a  class  type.  In  the  categorical  setting  described  above,  a 
formal  definition  of  an  object  instance  can  be  given. 

Definition  4.3.1  Object  Instance  -  An  object,  o,  is  a  tuple,  o  =  {t],CT,iv)  where  77  is  a  unique 
name  from  the  set  in  the  class  type  model  representing  the  class  sort,  CT  is  the  class  type  model, 
and  TT  is  a  set  of  variables  indexed  on  attributes  defined  in  the  class  type,  {ai,a2,  ...an}-  An  object 
is  a  member  of  a  class,  C  if  rj  is  in  the  class  type  model  set  representing  Ccs  ■ 

The  unique  name  of  the  object,  77,  is  assigned  at  object  creation  and  does  not  change  over  the  life  of 
the  object,  while  tt  represents  the  current  state  of  the  object  and  may  be  modified.  The  class  type 
model,  CT,  defines  how  a  given  object  is  interpreted  and  generally  does  not  change.  However,  as 
discussed  in  Section  4.4,  because  an  object  of  a  subclass  is  a  member  of  the  superclass  as  well,  an 
object  may  be  reduced  to  its  superclass  representation  in  which  case  the  class  type  model  becomes 
the  superclass  type  model.  When  an  object  name  is  pa.ssed  as  a  parameter  to  a  class  operation, 
the  values  upon  which  operations  act  are  the  values  of  the  variables  in  tt. 

Attributes  are  implicitly  defined  in  the  class  type  through  the  definition  of  attribute  viewer 
operations.  These  attribute  viewers  are  actually  projection  functions  and  return  a  single  attribute 
value  from  tt.  An  attribute  viewer,  a,  defined  in  a  class  type,  C,  is  an  operation  from  the  class 
sort  of  C,  Ccs,  to  a  second  sort,  Sa,  which  includes  all  valid  attribute  values  (i.e.,  a  :  Ccs-^Sa)- 
Therefore,  in  an  object  instance  of  class  C,  a  variable  in  tt  indexed  on  attribute  a  must  take  on 
values  in  Sa-  Formally,  tt  is  defined  as 

TT  =  {uq  :  5a  I  q  e  attributes(C)} 

where  attributes  (C )  is  the  set  of  all  attributes  implicitly  defined  by  attribute  viewer  operations 
from  the  class  type  C. 
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Because  the  reduct  functor  creates  models  of  one  class  from  another,  an  object-reduct  function 
may  be  defined  to  create  objects  in  one  class  from  objects  in  another.  The  effect  of  the  object- 
reduction  function  mirrors  the  effect  of  the  reduct  functor  and  is  defined  similarly. 

Definition  4.3.2  Object-Reduct  Function  -  Given  a  specification  morphism,  a  ■.  C  ^  D, 
between  two  class  types  and  Dee  Q  the  object-reduet  function,  denoted  _  reduces  object 
instances  of  class  D  to  instances  of  class  C  as  follows: 

ohe-T)  =  ohD-P 

ohc-CD  =  obij  |ct  (4.2) 

obc-TT  =  {tto,  I  Ua  €  obD.TT  A  o  S  attributes{C)} 

Therefore,  when  a  specification  morphism  exists  between  two  class  types,  objects  of  one  type 

can  be  created  from  objects  of  the  other  as  shown  in  Theorem  IV. 1. 

Theorem  IV.  1  Given  a  specification  morphism,  a  :  C  ^  D,  between  two  internally  consistent 
class  types  such  that  Dee  Q  Cee,  the  object-reduct  function,  as  defined  in  Definition  4-3.2,  exists. 

Proof:  Because  C  and  D  are  defined  consistently  the  category  of  models  for  each  specification 
(Mod[C]  and  Mod[D])  exists  and  a  induces  the  reduct  functor  .  I,,:  Mod[D]— >Mod[C]. 

1.  Since  Dee  Q  Cee,  the  object  name  of  each  object  in  D  exists  in  C  and  thus  ohe-r]  =  obxj.Ty. 

2.  obc-CT  is  defined  by  the  reduct  functor  _  \a. 

3.  Since  all  attributes  defined  in  C  are  mapped  to  attributes  in  D  by  cr,  there  exists  a  corre¬ 
sponding  variable  in  obp.Tr  for  each  attribute  variable  in  obc.TT. 

□ 

Example  4.3.2  illustrates  the  desired  effect  of  the  object-reduct  function  on  object  instances. 

Example  4.3.2  Given  the  class  type  definitions  of  C  and  D  and  models  Cmod  and  Dmod  as 
defined  in  Example  4-3.1,  the  objects  obc  and  objj  can  be  defined  over  Cmod  and  Dmod.  If  oho 
is  the  tuple  {t],  Dmod,  {01,02}),  where  oi  is  a  value  in  set  S3  and  03  is  a  value  in  set  Sa,  then 
obc  =  {r],  Cmod,  {oi})  where  oi  is  a  value  in  set  S3  and  Cmod  =  Dmod  |cr. 
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Because  functions  and  sets  are  copied  from  models  of  one  class  to  create  models  of  another,  the 
functions  must  provide  the  same  behavior  on  objects  of  both  classes.  This  behavioral  equivalence 
is  shown  by  the  commutative  diagram  in  Figure  4.5.  Theorem  IV. 2  states  that  this  diagram  does 
in  fact  commute. 


Theorem  IV. 2  If  a  :  C  —*  D  is  a  specification  morphism  between  two  internally  consistent  spec¬ 
ifications  and  fc  is  a  function  in  the  model  of  C  created  from  the  function  cr{f)D  in  the  model 
of  D  via  the  reduct  functor  induced  by  a  such  that  fc  =  (^{f)D,  then  for  all  objects,  d  E  D, 
fc{d  \a)  =  cr{f)D{d)  \„. 

Proof:  Assume  without  loss  of  generality  that  the  attributes  ai  ...  o„  £  attributes{D  j^)  and  that 
ui  ...  Qq  €  attributes{D)  such  that  attributes{D  |o-)  C  attributes {D) .  Also,  assume  that  if  d  l^.  = 
{t],  D,  ai  ...  Og)  then  a{f)D{d)  =  (t/,  D,  bi  ...  bq).  Note:  If  d  =  {rj,  D,  oi  ...  a,)  then  d  =  {rj,  D  |o^, 

Ql  ...  On)- 

Then,  if  d  =  (tj,  D,  ai  ...  a,), 

o-(/)D(d)  !<,  =  (T{f)D{{rt,D,ai...aq))\„ 

=  {v,D,bi.:bq)))\a 

=  {v<D\<T,bi...bn))) 

=  M(v,D\,r,ai...an)) 

=  /c(d  |cr) 


□ 
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4-4  Inheritance 


Class  inheritance  plays  an  important  role  in  object-orientation;  however,  the  correct  use  of 
inheritance  is  not  uniformly  agreed  upon.  Many  languages  provide  “ad-hoc”  inheritance  that  allows 
a  subclass  to  redefine  or  even  remove  attributes  or  operations  inherited  from  its  superclass.  However, 
most  authors  see  the  necessity  to  restrict  the  amount  of  modification  freedom  in  a  subclass.  In 
this  research,  I  require  a  generalization-specialization  inheritance  relationship.  There  are  two  types 
of  inheritance  that  satisfy  the  generalization-specialization  relationship:  extension  and  restriction. 
In  an  extension,  a  subclass  simply  adds  new  attributes  or  operations,  whereas  in  a  restriction  a 
subclass  constrains  attribute  values  from  a  superclass.  To  allow  a  subclass  to  be  freely  substituted 
for  its  superclass  in  any  situation  and  to  make  reasoning  about  the  class’s  properties  easier,  I  require 
that  a  subclass  only  extend  the  features  of  its  superclass.  Liskov  defines  these  desired  effects  as  the 
“substitution  property”  (67): 

If  for  each  object  oi  of  type  S  there  is  an  object  02  of  type  T  such  that  for  all  programs  P 
defined  in  terms  of  T  the  behavior  of  P  is  unchanged  when  oi  is  substituted  for  02 ,  then  S  is 
a  subtype  of  T. 

Bourdeau  and  Cheng  (14)  interpret  the  substitution  property  to  mean  that  an  object  of  class  5  may 
be  substituted  for  an  object  of  class  T  at  any  point  in  time.  This  effectively  means  that  the  object 
of  class  S  may  be  in  any  valid  state  prior  to  its  substitution  for  a  class  T  object.  This  interpretation 
requires  that  a  subclass  object  must  always  be  in  a  state  that  directly  maps  to  a  state  defined  in 
its  superclass  and  only  allows  the  addition  of  substates  and  concurrent  states  within  the  subclass. 

I  find  Bourdeau  and  Cheng’s  interpretation  too  restrictive  and  interpret  the  substitution  property 
to  mean  that  a  subclass  object,  when  created  and  stimulated  only  within  an  environment  created 
for  its  superclass,  behaves  as  a  superclass  object.  My  interpretation  allows  a  subclass  object  to 
respond  to  new  messages  or  events  that  take  it  into  new  states  that  do  not  exist  in  its  superclass; 
however,  when  starting  in  the  initial  states  as  defined  in  the  superclass  and  only  responding  to 
messages  or  events  inherited  from  the  superclass,  the  subclass  object  must  behave  exactly  as  an 
object  from  its  superclass  and  may  not  enter  a  state  defined  only  in  the  subclass. 
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To  hold  to  this  notion  of  generalization-specialization  there  are  two  requirements:  (1)  the 
substitution  property  holds  and  (2)  class  consistency  is  maintained.  The  only  way  to  ensure  the 
substitution  property  holds  in  all  cases  is  to  ensure  that  the  effects  of  all  superclass  operations 
performed  on  an  object  are  equivalent  in  the  subclass  and  the  superclass.  Before  showing  how  the 
substitution  property  and  class  consistency  are  preserved,  object-equivalence  must  be  defined. 

Definition  4.4.1  Object-Equivalence  -  Two  objects,  cl  and  c2,  of  a  class  type  C  are  equivalent 
over  C  if  and  only  if  the  value  of  all  attributes  defined  in  C  are  equal  in  cl  and  c2,  or, 
cl  =c  c2  V  (a)  (a  e  attributes{C)  a(cl)  =  o(c2)) 

Now  I  can  present  a  formal  definition  of  the  substitution  property.  In  this  definition,  o'  is  the 
operation  in  class  D  inherited  from  class  C. 

'i  {d)  de  D  Aoe  operation${C)  =>  3  (c)  c  £  C  A  {c=c  d  =>  o(c)  =c  o'{d))  (4.3) 

An  acceptable  definition  of  inheritance  would  then  provide  a  mapping  from  the  sorts,  op¬ 
erations,  and  attributes  in  the  superclass  to  those  in  the  subclass  that  preserve  the  semantics  of 
the  superclass.  This  is  the  basic  definition  of  a  specification  morphism  and  provides  us  a  formal 
definition  of  inheritance. 

Definition  4.4.2  Inheritance  -  A  class  D  is  said  to  inherit  from  a  class  C,  denoted  D  <  C,  if 
there  exists  a  specification  morphism  from  C  to  D  and  the  class  sort  of  D  is  a  subsort  of  the  class 
sort  ofC  (i.e.,  Dca  Q  Cca)- 

This  definition  states  that  all  sorts  and  operations  from  class  C  are  embedded  in  class  D,  that 
a  new  sort,  the  class  sort  of  D,  is  defined  as  a  subsort  of  the  class  sort  of  C,  and  that  the  axioms  in 
C  are  theorems  in  D.  While  Definition  4.4.2  provides  a  concise,  mathematically  precise  definition  of 
inheritance,  its  ability  to  ensure  the  preservation  of  class  consistency  and  the  substitution  property 
as  stated  in  Equations  4.1  and  4.3  must  be  shown. 
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Before  proving  that  Definition  4.4.2  preserves  the  substitution  property,  two  lemmas  must  be 
proved.  The  first  lemma  shows  that  an  object  and  its  reduct  are  object-equivalent  and  the  second 
states  that  given  a  specification  morphism  between  two  classes,  an  object  in  the  subclass  is  also  an 
object  in  the  superclass. 

Lemma  4.4.1  Given  a  specification  morphism,  a  :  C  ^  D,'i  {d)  d£D^c  =  d\c=^c  =c  d. 

Proof:  By  Definition  4.3.2,  d\a  .t:  =  {a^  [  €  d.-ir  Aa  £  attributes{C)}  thus  it  is  obvious  that 

Va  €  attributes{C)  li  c  =  d\a  then  a{c)  =  a{d  1^)  and  by  Definition  4.4.1,  c  =c  d.  □ 

Lemma  4.4.2  If  there  exists  a  specification  morphism  between  two  classes  a  :  C  D  and  Dca  C 

Ccs  then  for  every  object  d  £  D  there  exists  some  c£  C  such  that  d  =c  c. 

Proof:  By  the  definition  of  a  specification  morphism,  cr  •.  C  ^  D,  &  reduct  functor,  .  \^,  creates 
models  of  C  from  models  of  D.  The  object-reduct  function  as  defined  in  Definition  4.3.2  takes 
objects  defined  over  D  and  creates  objects  defined  over  C  with  identical  attribute  values  for  all 
attributes  in  C.  Therefore,  ^  {d)  d  £  D  3  (c)  c  £  C  A  c  =  d  \„  and  by  Lemma  4.4.1,  c  =c  d.  □ 

Now  it  is  possible  to  show  that  inheritance,  as  defined  in  Definition  4.4.2,  does  in  fact  preserve 
the  substitution  property  and  thus  is  a  valid  definition  for  this  model. 

Theorem  IV. 3  Given  a  specification  morphism,  cr  :  C  D,  between  two  internally  consistent 
classes  C  and  D,  Dcs  C  Ccs,  (^nd  that  the  model  of  C,  Cmod  is  created  via  the  reduct  functor 
induced  by  a  from  the  model  of  D,  Dmod,  then  substitution  property  holds. 

Proof: 

1.  By  Lemma  4.4.2,  for  all  objects  in  D  there  exists  an  object  in  C  such  that  c  =  d\c^. 

2.  If  Cmod  is  constructed  from  Dmod  using  the  reduct  functor,  then  for  all  objects  o  £ 
operations{C)  there  exists  some  fc  G  Cmod  such  that  cr{f)D  G  Dmod  and  fc  —  cr{f)D. 
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3.  Then,  by  Theorem  IV. 2  V  (d)  3  (c)  such  that  d  E  D  A  c  E  C  then  0  =  ^1^  =>  f{c)  =  f{d 
)  =  f{d)  lo-,  or  /(c)  =c  o-(/)£i(d). 

□ 

4.4-1  Multiple  Inheritance.  Multiple  inheritance  requires  a  slight  modification  to  the 
notion  of  inheritance  as  defined  in  Definition  4.4.2.  The  set  of  superclasses  must  first  be  combined 
and  then  used  to  “inherit  from” . 

Definition  4.4.3  Multiple  Inheritance  -  A  class  D  multiply  inherits  from  a  collection  of  classes 
{Cl  ..  Cn\  if  there  exists  a  specification  morphism  from  the  colimit  of  {Ci  ..  Cn}  to  D  such  that 
the  class  sort  of  D  is  a  subsort  of  each  of  the  class  sorts  o/{Ci  ..  Cn}. 

The  colimit  operation  allows  the  combination  of  any  number  of  classes,  along  shared  parts,  to 
create  a  single  specification  with  all  the  sorts,  operations,  and  axioms  of  the  original  classes.  This 
colimit  specification  can  then  be  extend  with  the  definition  of  the  new  class  sort,  attributes,  and 
operations. 

This  definition  ensures  that  the  subclass  D  inherits  (in  the  sense  of  Definition  4.4.2)  from 
each  superclass  in  {Ci  ..  Cn}-  The  proof  is  shown  in  Theorem  IV.4  below. 

Theorem  IV.4  Given  a  specification  morphism  from  the  colimit  of  {Ci  ..  Cn}  to  D  such  that  the 
class  sort  of  D  is  a  subsort  of  each  of  the  class  sorts  of  [Ci  ..  Cn},  the  substitution  property  holds 
between  D  and  each  of  its  superclasses  {Ci  ..  Cn}- 

Proof:  In  the  category  Spec,  all  cocone  morphisms  from  any  Cj  E  {Ci  ..  Cn}  to  the  colimit 
specification  composed  with  the  extension  from  the  colimit  specification  to  D  is  a  specification 
morphism  from  Cj  to  D  as  shown  in  Figure  4.6.  Thus  multiple  inheritance  implies  a  specification 
morphism  between  each  Cj  and  D  and  thus  by  Theorem  IV.3,  the  substitution  property  holds.  □ 
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Figure  4.6  Multiple  Inheritance  Colimit 


It  is  important  to  note  that  Definition  4.4.3  only  ensures  valid  inheritance  when  all  operations 
are  fully  defined  in  each  specification  {C\  ..  Cn}.  Failure  to  ensure  fully  defined  operations  may 
result  in  an  inconsistent  colimit  specification. 

Consider  the  example  shown  in  Figure  4.7.  A  class  E  is  created  by  multiply  inheriting  from 
D'  and  D"  which  both  are  subclasses  of  an  superclass  C  where  the  operation  m  is  not  fully  defined. 
While  everything  works  syntactically,  the  resulting  class  is  inconsistent  due  to  the  axioms  defined 
in  D'  and  D”. 


x(e)  >  0  ^  x{m{e))  =  x{e)  +  1 
x{e)  >  0  x{m{e))  =  x(e)  +  2 

Both  D'  and  D"  are  valid  subclasses  of  C  yet  they  modified  the  behavior  of  a  m  in  such  a  way 
that  the  resulting  multiply  inherited  operation  definition  is  inconsistent.  Thus  class  consistency 
conditions  do  not  hold. 

4-5  Summary 

This  section  establishes  the  mathematical  foundation  for  a  formal  theory-based  model  of 
object-oriented  concepts  for  the  system  defined  in  Chapter  II  and  shown  in  Figure  2.2.  These 
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class  C  is 
import  Integer 
class  sort  C 
attributes 

X  :  C  — >  Integer 
operations 
m  :  C  ^  C 
axioms 

V  (c:  C)  x(c)  <  0  x(m(c))  =  x(c)  -  1 

end-class 


class  D'  is 

class  sort  D'  <  C 

axioms 

V  (d:  D)  x(d)  >  0  =>  x(m(d))  =  x(d)  +  1 
end-class 


class  D"  is 

class  sort  D"  <  C 

axioms 

V  (d:  D)  x(d)  >  0  x(m(d))  =  x(d)  +  2 

end-class 


class  E  is 
import  Integer 
class  sort  E  <  D',  D" 
attributes 

X  :  E  — >  Integer 
operations 
m  :  E  — >  E 
axioms 

V  (e:  E)  x(e)  <  0  ^  x{m(e))  =  x(e)  -  1; 

V  (e:  E)  x(e)  >  0  ^  x(m(e))  =  x(e)  -I-  1; 

V  (e:  E)  x(e)  >  0  x(m(e))  =  x(e)  -t-  2 

end-class 

Figure  4.7  Inconsistent  Multiple  Inheritance 
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foundations  are  general  in  nature  and  are  applicable  to  a  number  methodologies  within  the  object- 
oriented  paradigm. 

First,  classes  were  defined  as  theory  presentations  or  specifications  within  the  category  Spec 
while  the  models  of  each  class,  defined  by  the  Mod  functor,  form  a  category  within  the  category 
Cat.  Models  of  a  class  were  associated  with  an  implementation  of  the  class  and  a  mathematically 
sound  method  for  creating  compatible  models  of  a  class  was  defined.  This  method  is  based  on  the 
existence  of  a  specification  morphism  between  classes  and  thus  the  existence  of  a  reduct  functor 
that  creates  models  of  one  specification  from  models  of  another.  The  theoretical  concept  of  an 
object  instance  was  then  introduced  along  with  an  object  “reduct”  function  based  on  the  reduct 
functor.  These  concepts  were  used  to  show  the  desired  effect  of  inheritance. 

Finally,  a  formal  definition  of  inheritance  was  presented  based  on  the  “substitution  property” . 
This  formal  definition  of  inheritance  was  then  shown  to  preserve  the  substitution  property  in 
Theorem  IV.3.  These  results  were  then  extended  to  multiple  inheritance.  The  next  two  chapters 
build  on  the  mathematical  foundations  presented  in  this  chapter  by  defining  a  theory-based  object 
model  and  its  semantics  that  incorporates  the  concepts  of  classes,  objects,  and  inheritance  defined 
in  this  chapter. 
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V.  Formal  Object  Modeling  Technique  Semantics 

5.1  Introduction 

This  chapter  present  a  formal  semantics  for  a  restricted  version  of  Rumbaugh’s  OMT.  These 
restrictions  are  imposed  on  each  of  the  three  OMT  models-object,  dynamic,  and  functional-  to 
ensure  automatic  translation  from  graphical  notation  to  algebraic  specifications.  The  semantics  of 
the  restricted  OMT  models  are  arrived  at  by  defining  a  formal  semantics  for  each  of  Rumbaugh’s 
models.  Section  5.2  describes  the  basic  requirements  placed  on  a  graphically  based  diagram  in 
order  to  ensure  automated  translation.  Section  5.3  describes  the  restrictions  and  formal  semantics 
for  the  object  model  while  Sections  5.4  and  5.5  describe  the  restrictions  and  formal  semantics  for 
the  dynamic  and  functional  models. 

5.2  Translation  Requirements 

Translation  of  graphically  based  models  into  algebraic  specifications  in  the  category  Spec 
requires  that  the  two  criteria  be  met.  First,  all  entities  in  the  model  must  correspond  to  components 
of  an  algebraic  specification  or  be  defined  using  category  theory  constructs.  This  means  that  all 
important  features  of  the  model  must  be  representable  as  specifications,  functions,  sorts,  first-order 
axioms  defined  over  those  sorts  and  functions,  or  category  theory  operations  between  specifications. 
For  instance,  in  a  data  fiow  diagram,  a  process  translates  to  a  function  while  data  fiows  between 
processes  are  defined  by  sorts. 

The  second  requirement  is  that  all  models  be  deterministic,  that  is,  there  must  be  a  single 
valid  interpretation  of  the  model.  Again,  in  a  data  flow  diagram,  the  usual  interpretation  is  that 
the  processes  and  data  flows  within  the  diagram  only  define  possible  data  flow  paths,  and  does 
not  imply  any  specific  sequence  of  control.  While  the  flow  of  data  through  the  system  may  be 
obvious  to  a  user  based  on  the  types  of  data  involved  and  certain  naming  conventions,  the  normal 
interpretation  of  data  flow  diagrams  does  not  provide  the  degree  of  determinism  necessary  to  use 
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them  in  an  automated  system  without  modifying  the  semantics  or  adding  additional  information. 
Therefore,  the  translation  requirements  for  any  graphically  based  model  are  given  below. 

I.  All  model  entities  must  be  represented  by  pure  functions,  sorts, 
first-order  axioms,  or  category  theory  constructs. 

II.  Model  semantics  must  be  deterministic. 

5.3  Object  Model 

This  section  discusses  the  semantics  defined  for  the  OMT  object  model  and  the  problems 
encountered  in  translating  it  into  algebraic  specifications.  Section  5.3.1  presents  a  brief  overview 
of  the  OMT  object  model.  Section  5.3.2  describes  proposed  restrictions  to  the  OMT  object  model, 
and  Section  5.3.3  derives  the  semantics  of  the  restricted  object  model  from  the  formal  OMT  object 
model  semantics  defined  by  Bourdeau  and  Cheng  (14). 

5.3.1  Overview  of  Rumbaugh’s  Object  Model.  The  OMT  object  model  defines  the  struc¬ 
ture  of  a  domain  based  on  classes  of  objects  and  the  relationships  between  them.  A  class  defines 
the  structure  of  a  similar  set  of  objects.  This  structure  is  defined  by  attributes,  which  are  data  that 
describe  various  aspects  of  an  object,  and  operations  that  describe  how  an  object  behaves.  Relation¬ 
ships  between  objects  fall  into  one  of  three  categories:  associations,  aggregation,  and  inheritance. 
Associations  are  general  relationships  between  two  or  more  classes.  Aggregation  describes  a  “part- 
of”  relationship  between  an  object  and  a  subobject  which  is  used  to  make  up  the  aggregate  object. 
Inheritance  describes  a  “generalization-specialization”  relationship  between  two  classes  of  objects 
where  if  A  is  a  subclass  of  B  then  objects  of  class  A  are  objects  of  class  B  as  well. 

Figure  5.1  shows  an  example  of  a  typical  OMT  object  model  domain,  a  rocket.  The  OMT 
diagram  shows  six  object  classes:  Rocket,  Airframe,  FuelTank,  PropulsionDevice,  JetEngine,  and 
RocketEngine.  The  lines  drawn  between  object  classes  represent  relationships  between  them.  The 
0  on  the  line  from  the  Rocket  to  the  Airframe,  FuelTank,  and  PropulsionDevice  denotes  an  aggre- 
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Figure  5.1  Typical  Object  Model 


gation  relationship.  That  is,  a  Rocket  consists  of  an  Airframe,  FuelTank,  and  a  PropulsionDevice. 
The  A  symbol  between  the  PropulsionDevice  class  and  the  JetEngine  and  RocketEngine  classes 
denotes  inheritance.  Thus  an  object  that  is  a  member  of  the  JetEngine  or  RocketEngine  class  is  also 
a  member  of  the  PropulsionDevice  class.  Finally,  the  line  between  the  FuelTank  and  the  JetEngine 
denotes  an  association  that  relates  members  of  the  FuelTank  class  to  members  of  the  JetEngine 
class.  The  text  below  the  class  name  in  object  class  rectangles  defines  attributes.  Thus  a  FuelTank 
object  has  two  attributes,  weight  and  capacity,  each  of  which  is  a  real  datatype.  The  endpoints  of 
an  association/aggregation  line  denotes  a  particular  multiplicity  in  the  association  and  aggregation 
relationships  as  show  in  Figure  5.2.  These  multiplicities  define  the  number  of  relationships  in  which 
a  particular  object  may  participate.  In  Figure  5.2,  each  object  at  the  other  end  of  the  relationship 
may  be  in  a  relationship  with  exactly  one,  zero  or  more,  zero  or  one,  one  or  more,  or  a  numerically 
specified  number  of  objects  of  the  type  Class. 

5.3.2  The  Restricted  OMT  Object  Model.  The  only  problem  inherent  in  Rumbaugh’s 
definition  of  the  object  model,  as  described  in  Section  5.3.1,  is  the  ability  of  the  user  to  define 
operations.  This  capability  allows  users  to  define  operations  that  have  no  relation  to  the  dynamic 
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Exaolty  one 


Zero  or  more 


Zero  or  One 


One  or  more 


Numerically  Specified 


Figure  5.2  Relationship  Multiplicities 

or  functional  model  and,  therefore,  has  the  potential  to  introduce  inconsistencies.  In  this  research, 
I  take  the  approach  that  all  operations  are  defined  as  either  a  process  in  the  functional  model  or 
an  action  in  the  dynamic  model.  Therefore,  the  only  restriction  to  the  OMT  object  model  is  to 
disallow  the  introduction  of  operations. 


Assumption  V.l  All  class  methods  and  operations  are  introduced  in  the  OMT  dynamic  or  func¬ 
tional  model. 


5.3.3  Object  Model  Semantics.  Relatively  little  exists  describing  the  formal  semantics  of 
object  models.  Some  generic  data  base  work  (31)  describes  structural  aspects  of  object-oriented 
systems  but  they  fail  to  provide  a  complete  semantics  for  an  OMT-type  object  diagram.  Bourdeau 
and  Cheng  (14)  have  developed  a  formal  semantics  for  an  extended  version  of  the  OMT  object 
model  notation.  They  use  the  Larch  specification  language  (43)  to  describe  modular  algebraic 
specifications  based  on  the  OMT  object  model.  In  this  section  I  formally  define  the  semantics  of 
the  OMT  object  model  based  on  the  semantics  proposed  by  Bourdeau  and  Cheng.  (Note:  the 
following  rules  are  a  subset  of  those  defined  by  Bourdeau  and  Cheng  in  (14).  Many  of  their  rules 
deal  with  OMT  object  model  extensions,  such  as  state,  which  are  part  of  the  basic  OMT  dynamic 
or  functional  models  and  are  omitted  here.) 
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The  object  model  itself  is  a  specification  which  simply  includes  the  object  classes  and  associ¬ 


ations  derived  from  the  object  diagram.  Classes  and  associations  are  defined  as  follows. 


Definition  5.3.1  A  Restricted  OMT  Object  Model,  OM,  is  a  set  of  specifications  determined 
by  Definitions  5.3.2  through  5.3.5. 


Definition  5.3.2  An  Object  Class  C  in  an  object  model  O  defines  a  specification  where 

(OM-1)  The  class  C  is  denoted  by  a  sort  of  the  same  name. 

(OM-2)  For  each  attribute,  a,  in  class  C  of  type  D,  there  is  a  function  signature 

a-.C^D 

(OM-3)  If  D  in  rule  (OM-2)  references  a  separate  class  specification,  then  the  specification  for  D 
is  included  (imported)  into  the  specification  of  class  C. 

The  rules  above  define  the  structural  aspect  of  object  classes  only.  Relational  aspects  such 
as  association,  aggregation,  and  inheritance  are  defined  below.  The  next  three  definitions  define 
additional  rules  which,  when  used  on  aggregate  classes,  associations,  and  subclasses  fully  defines 
the  object  model. 


Definition  5.3.3  An  Aggregate,  with  components  D\...Dk  defines  a  specification  D  using  rules 
OM-1  -  OM-3  where 

(OM-4)  For  each  component  Di...Dk,  the  aggregate  relation  is  denoted  by  a  predicate  has-part 
which  relates  class  D  to  Dn-  If  the  component  has  a  role  name  in  the  aggregation,  the  role 
name  is  used  in  place  o/ has-part. 

has-part :  D,  Dn  Boolean 

(OM-5)  Axioms  defining  the  multiplicity  constraints  of  the  aggregation  are  added  to  D. 


Thus  rules  OM-4  and  OM-5  define  predicates  in  the  aggregate  class  definition  that  relate  a 
given  aggregate  object  to  its  components.  Bourdeau  and  Cheng  also  provide  a  detailed  method¬ 
ology  for  defining  multiplicity  axioms;  however,  in  this  research  I  use  equivalent  axioms  defined 
in  Section  6.4.1.  The  next  relation  defined  by  Bourdeau  and  Cheng  is  the  subtype  relation  which 
implements  inheritance. 
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Definition  5.3.4  Let  D  be  a  subtype  of  class  C.  Then  a  specification  is  defined  for  both  C  and 
D  using  rules  OM-1  -  OM-5  and  where 

(OM-6)  The  subtype  relation  is  defined  by  an  operation  named  simulates  in  D  relating  class  D  to 

C. 

simulates  ■.  D  C 

In  essence,  the  simulates  operation  takes  an  object  of  the  subtype  and  produces  an  object  of 
the  supertype,  thus  implementing  Bourdeau  and  Cheng’s  interpretation  of  the  substitution  property. 
As  discussed  in  Section  4.3,  I  use  a  slightly  different  interpretation  of  the  substitution  property 
than  do  Bourdeau  and  Cheng.  Basically,  they  assume  that  a  subtype  object  D  must  always  be 
substitutable  for  its  supertype  object  C,  while  I  interpret  the  property  to  mean  that  if,  from  object 
creation,  an  object  from  class  D  is  restricted  only  to  operations  defined  on  class  C  then  the  object 
is  indistinguishable  from  an  object  of  class  C.  Bourdeau  and  Cheng  define  the  following  constraint 
that  the  simulates  operation  must  satisfy: 

V  (d  :  D)  a  e  attributes(d)  =>  a{d)  =  a{simulates{d))  (5.1) 

Bourdeau  and  Cheng’s  constraint  restricts  subtype  objects  further  than  my  interpretation, 
which  formalized  is: 

V  (d  ;  Z3)  a  e  attributes{D)  A  o  €  operations{D)  A  a(d)  =  a{simulates{d))  .  . 

=>  a{p' {simulatesid)))  =  a{simulates{o{d)))  ^  ’  ' 

where  o'  is  the  inherited  operation  in  D  derived  from  operation  o  in  C.  Equation  5.2  incorporates 
the  intent  of  Equation  5.1  given  my  interpretation  of  the  substitution  property. 

Definition  5.3.5  An  Association,  R,  relating  objects  from  classes  Di...Dk  defines  a  specification 
A  using  rules  OM-1  -  OM-3  and  where 

(OM-7)  The  association  R  is  denoted  by  a  predicate  of  the  same  name  in  specification  A: 

R  :  Di...Dk  —*  Boolean 

(OM-8)  Axioms  defining  the  multiplicity  constraints  of  R  are  added  to  A. 
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In  effect,  rules  (OM-7)  and  (OM-8)  state  that  for  an  association,  a  new  specification  is  created 
with  a  boolean  predicate  of  the  same  name  which  defines  which  objects  of  the  two  associated  classes 
are  related. 

5.4  Dynamic  Model 

This  section  discusses  the  semantics  of  the  OMT  dynamic  model  and  the  problems  encoun¬ 
tered  in  translating  it  into  algebraic  specifications.  Section  5.4.1  presents  a  brief  overview  of  the 
dynamic  model.  Section  5.4.2  discusses  the  problems  in  translating  the  dynamic  model  into  al¬ 
gebraic  specifications.  Section  5.4.3  defines  restrictions  to  the  dynamic  model  to  counter  those 
problems,  and  Section  5.4.4  derives  the  semantics  of  the  restricted  dynamic  model  from  the  formal 
semantics  of  Harel’s  statecharts  (45). 

5.4-1  Overview  of  Rumbaugh’s  Dynamic  Model.  The  concept  of  state  is  vital  to  object- 
orientation.  State,  as  defined  by  Rumbaugh,  is  an  abstraction  of  an  object’s  attribute  values  and  is 
represented  in  his  model  via  a  statechart.  A  typical  statechart  is  shown  in  Figure  5.3.  Statecharts 
have  five  parts:  states,  transitions,  events,  guards,  and  actions.  The  state  of  a  system  “summarizes 
the  information  concerning  past  input  and  that  is  needed  to  determine  the  behavior  of  the  system 
on  subsequent  inputs”  (47:13).  Therefore,  a  system  typically  resides  in  a  state  between  inputs  and 
may  change  state  based  on  additional  input.  Transitions  are  the  changes  of  state  based  on  given 
input  and  the  current  state.  Transition  labels  define  the  input  event,  guard,  and  actions  associated 
with  a  transition  as  shown  below. 

event  [  guard-condition  ]  /  action\...actionn 

Events  are  the  instantaneous  transmittal  of  information  from  one  object  to  another.  In  statecharts, 
communication  is  assumed  to  occur  as  global  broadcasts.  If  an  object  generates  an  event,  it  is 
received  by  all  other  objects  who  have  a  transition  labeled  with  the  same  event  name.  Besides  the 
receipt  of  the  event  itself,  additional  information  may  be  transmitted  via  event  parameterization. 
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It  is  assumed  that  if  there  is  no  explicit  transition  from  a  state  S  upon  receipt  of  an  event,  E,  then 
if  event  E  is  received  while  in  state  S,  no  actions  occur.  Guard  Conditions  allow  a  system  to  check 
that,  upon  receipt  of  an  event,  certain  conditions  hold  before  a  transition  takes  place.  Actions 
are  the  behavior  initiated  by  some  transition.  Actions  include  computation  of  data,  modification 
of  object  attributes,  or  broadcasting  of  additional  events.  Although  Harel  and  Rumbaugh  allow 
statecharts  to  place  actions  inside  states  (the  equivalent  of  a  Moore  machine  from  finite  automata) 
as  well  as  on  transitions,  for  convenience,  in  this  research  I  limit  all  actions  to  transitions  (a  Mealy 
machine).  This  does  not  represent  a  semantic  restriction  as  the  equivalence  of  Mealy  and  Moore 
machines  is  well  known  (47:43).  A  special  type  of  action  is  a  send  action.  A  send  action  specifies 
that  an  event  is  to  be  broadcast  to  the  system.  A  typical  send  action  might  be: 

send  ( event-name{parameter  list) ) 

In  this  case  the  event-name  is  broadcast  to  all  receiving  objects  along  with  all  data  passed  via  the 
parameter  list.  Other  actions  become  operations  on  the  current  object. 


withdrawal(a,x)  [bal(a)  >=  x]/debit{a,x) 


Figure  5.3  Account  Dynamic  Model 

Statecharts  often  allow  for  concurrent  states  or  substates.  Concurrent  state  diagrams  are 
used  when  the  attributes  of  a  class  type  may  be  partitioned  into  subsets.  The  state  of  an  object 
becomes  a  tuple  consisting  of  the  object  state  in  eax:h  concurrent  state  diagram.  An  example  of 
a  concurrent  state  diagram  is  shown  in  Figure  5.4.  In  this  example,  events  el,  e2,  and  e3  cause 
the  first  component  of  the  object  state  to  change  while  events  e4,  e5,  and  e6  cause  the  second 
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component  of  the  object  state  to  change.  The  events  in  the  concurrent  diagrams  do  not  have  to  be 
distinct  while  the  effects  of  those  events  on  object  attributes  are.  For  example,  assume  the  object 
state  of  an  object  whose  dynamic  model  is  represented  by  Figure  5.4  is  (1, 4).  If  the  following  string 
of  events,  (el,  e4,  e5,  e2),  is  received,  the  object  ends  up  in  state  (3, 6)  by  the  following  transitions. 

(1,4)  ^  (2,4)  ^  (2,5)  ^  (2,6)  ^  (3,6) 


Figure  5.4  Concurrent  State  Diagram 


In  a  non-concurrent  statechart,  an  object  must  be  in  a  single  state;  however,  within  a  state, 
substates  may  exist  that  refine  the  state  allowing  the  object  to  change  its  substate  while  remaining 
in  the  superstate  as  shown  in  Figure  5.5.  Such  substates  “inherit”  the  transitions  of  their  super¬ 
state.  In  the  theory-based  object  model,  substates  are  handled  similarly  to  concurrent  states  -  by 
adding  additional  substate  attributes  whose  values  are  only  meaningful  when  the  object  is  in  the 
appropriate  superstate.  Thus,  the  object  in  Figure  5.5  must  always  be  in  a  superstate  1,  2,  or  3; 
however,  while  in  state  2,  the  events  e4,  e5,  and  e6  allow  the  object  to  change  it  substate  and  re¬ 
main  in  state  2.  Once  an  e2  event  is  received,  the  superstate  transitions  to  state  3  and  the  substate 
attribute  value  is  no  longer  meaningful.  The  object  will  not  change  state  even  if  an  e4,  e5,  or  e6 
event  is  received. 
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Figure  5.5  SubState  Diagram 


5.4-^  Dynamic  Model  Translation  Problems.  This  section  discusses  problems  inherent  in 
translating  the  dynamic  model,  as  specified  by  Rumbaugh,  into  algebraic  theories  and  describes  the 
incompatibility  of  the  dynamic  model  with  the  translation  requirements  described  in  Section  5.2. 

There  is  little  problem  associated  with  translating  individual  statecharts  into  sorts,  functions, 
and  first-order  axioms  in  algebraic  specifications.  Each  statechart,  substatechart,  and  component 
of  concurrent  statecharts  defines  an  attribute  function.  The  states  within  each  diagram  define  a 
sort  where  the  values  in  the  sort  are  the  states  in  the  diagram.  Each  state  also  defines  a  nullary 
function  for  each  individual  state  or  substate.  Events  and  actions  translate  into  functions.  Axioms 
are  used  to  define  the  effects  of  transitions  on  state  attributes  and  actions.  Additional  axioms  may 
also  be  generated  to  show  that  receipt  of  events  with  no  defined  transitions  from  a  given  state  result 
in  no  changes.  Actions  are  modelled  as  either  functions  representing  operations  on  the  object  or  as 
events  to  be  broadcast  to  the  system.  Use  of  the  categorical  constructs  of  morphisms  and  colimits 
allows  specification  of  event  transmission. 

Even  though  translation  seems  straightforward,  some  inconsistencies  may  occur  when  inher¬ 
itance  is  taken  into  account.  For  instance,  substates  may  be  used  to  refine  a  superclass  state  as 
long  as  the  superclass  events  defining  transitions  from  the  superstate  are  not  used  in  the  substate 
diagram.  Attempting  to  override  an  exit  transition  from  the  superstate  results  in  inconsistencies  as 
shown  in  Figure  5.6.  Rumbaugh  interprets  this  statechart  to  mean  that  when  an  object  is  in  state 
2b  and  event  e2  occurs,  the  substate  transition  overrides  the  superstate  transition  and  the  state 
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moves  to  2c;  however,  this  violates  the  substitution  property  since  the  subclass  object  no  longer 
behaves  as  a  superclass  object. 


Figure  5.6  Invalid  Substate  Diagram 


Figure  5.7  shows  a  valid  concurrent  state  diagram.  This  diagram  is  valid  since  the  states  and 
events  of  the  two  concurrent  subdiagrams  are  distinct.  However,  not  all  concurrent  dynamic  models 
satisfy  this  consistency  condition.  Concurrent  state  diagrams  are  only  valid  when  the  attributes  of 
the  class  are  partitionable  and  the  actions  in  a  concurrent  subdiagram  affect  only  the  attributes  in 
a  single  partition.  When  this  condition  is  violated,  inconsistencies  between  diagrams  may  result. 
Therefore,  when  a  concurrent  statechart  is  introduced  in  a  subclass  to  refine  the  dynamic  model, 
the  actions  associated  with  transitions  in  the  concurrent  component  must  affect  only  the  subclass 
attributes.  This  requires  that  the  actions  in  the  concurrent  component  be  operations  defined  in  the 
subclass  and  that  those  actions  modify  only  subclass  attributes. 


Figure  5.7  Inheritance  of  Dynamic  Behavior  -  Concurrent  Diagram 


5.4-3  The  Restricted  OMT  Dynamic  Model.  With  the  exception  of  substate  transition 
overriding,  there  are  no  inconsistencies  with  statecharts  as  used  by  Rumbaugh;  however,  for  sim¬ 
plicity,  I  limit  the  dynamic  model  to  a  Mealy  machine  representation  where  all  actions  must  occur 
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on  transitions  as  discussed  in  Section  5.4.1.  I  also  assume  that  if  the  user  specifies  guard  conditions 
for  a  set  of  transitions  on  event  e  from  state  s,  then  the  guards  for  that  set  of  transitions  are  con¬ 
sistent  and  complete.  This  may  require  the  user  to  define  transitions  that  “do  nothing” ;  however, 
this  assumption  ensures  that  a  complete  and  consistent  set  of  axioms  can  be  generated  from  the 
dynamic  model  without  resorting  to  considerable  reasoning  about  the  validity  of  the  guard  condi¬ 
tions.  I  also  assume  that  all  guard  conditions  are  written  in  0-Slang  syntax  and  are  based  only 
on  the  parameters  passed  to  the  object  by  the  event  and  the  object’s  attribute  values.  The  user 
may  specify  multiple  actions  on  a  transition;  however,  since  non-send  actions  represent  operation 
invocations  and  there  is  no  sequence  implied  by  the  order  of  actions,  multiple  non-send  actions 
occur  in  parallel.  If  two  actions  have  a  specific  sequence,  the  user  can  easily  create  an  operation 
that  implements  this  sequential  behavior;  therefore,  in  general,  only  one  non-send  action  is  specified 
per  transition.  My  restrictions  to  Rumbaugh’s  dynamic  model  are  shown  below. 

1.  Assumption  V.2  All  actions  must  occur  on  transitions  between  states. 

2.  Assumption  V.3  All  guard  conditions  must  be  written  in  valid  0-Slang  syntax  using  only 
event  parameters,  object  attributes,  and  constants. 

3.  Assumption  V.4  Guard  conditions  for  a  set  of  transitions  for  a  single  event  are  consistent 
and  complete. 

4.  Assumption  V.5  Only  one  non-send  action  may  be  specified  per  transition. 

5.  Assumption  V.6  Events  on  transitions  leading  from  a  superstate  may  not  be  used  in  sub¬ 
states  (i.e.,  no  overriding  superstate  transitions). 

6.  Assumption  V.7  Concurrent  statecharts  must  partition  the  attributes  affected  by  methods 
in  different  concurrent  sections  into  disjoint  sets. 
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5.^.^  Dynamic  Model  Semantics.  In  this  section  I  formally  define  the  semantics  of  the 
restricted  dynamic  model.  As  expected,  the  semantics  of  dynamic  model  statecharts  are  based  the 
standard  automata  definition  (47:43). 

Definition  5.4.1  A  Mealy  machine  is  a  six-tuple  M  =  (Q,  S,  A,(5,  A,go)  where 

•  Q  is  a  finite  set  of  states. 

•  T,  is  a  input  alphabet. 

•  A  is  the  output  alphabet. 

•  S  is  the  transition  function  mapping  Q  x  E  Q. 

•  X  is  a  mapping  from  Q  — >  A  giving  the  output  for  each  transition. 

•  qo  £  Q,  is  the  initial  state. 

The  mapping  from  the  Mealy  machine  to  a  statechart  is  straightforward  and  given  in  the 
definition  of  a  statechart  below. 

Definition  5.4.2  A  dynamic  model  Statechart  is  a  six-tuple  M  =  (Q,  S,  A,  A,  go)  where 

•  Q  is  the  set  of  states  in  the  statechart. 

•  E  is  the  set  of  input  events. 

•  A  is  the  set  of  output  events  and  actions. 

•  6  is  the  transition  function  mapping  Q  xE  Q  based  on  transition  arrows  and  guard  condi¬ 
tions. 

•  X  is  a  mapping  from  Q  — >  A  giving  the  output  for  each  transition  based  on  transition  arrows 
and  guard  conditions. 

•  Qo  &  Q,  is  the  initial  state. 
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Substates  and  concurrent  states  are  a  simple  translation  into  this  ordinary  automata  (45) 
due  to  Rumbaugh’s  simplification  of  statecharts  and  the  additional  restrictions  of  Section  5.4.3. 
Substates  are  “unfolded”  into  their  superstate  by  transferring  incoming  superstate  transitions  to 
the  initial  state  of  the  substate  statechart  and  adding  outgoing  superstate  transitions  to  each 
substate  as  shown  in  Figure  5.8. 


Figure  5.8  Unfolding  Substates  into  a  Single  Statechart 


Concurrent  state  diagrams,  such  as  shown  in  Figure  5.4,  are  translated  by  creating  a  state  for 
each  combination  of  concurrent  state  values  and  adding  the  appropriate  transitions.  The  translation 
of  Figure  5.4  is  shown  in  Figure  5.9.  In  this  example,  the  events  and  operations  of  the  two  concurrent 
subdiagrams  are  disjoint.  Although  operations  must  be  disjoint,  events  may  be  shared.  If  events 
el  and  e4  in  Figure  5.4  are  equivalent  (i.e.,  they  have  the  same  name),  then  the  translation  to  a 
single-level,  non-concurrent  diagram  is  shown  in  Figure  5.10.  In  this  example,  state  (1,5)  is  not 
included  since  event  el  now  transitions  the  state  directly  from  (1,4)  to  (2,5).  The  composition  of 
operations  ml  and  m4  is  not  problematic  since  in  the  restricted  dynamic  model  they  are  required 
to  modify  a  disjoint  sets  of  attributes. 
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5.5  Functional  Model 


This  section  discusses  the  OMT  functional  model  and  the  problems  encountered  in  attempting 
to  translate  it  into  algebraic  specifications.  Section  5.5.1  presents  an  overview  of  the  OMT  functional 
model,  Section  5.5.2  discusses  the  problems  encountered  in  trying  to  translate  the  OMT  functional 
model,  Section  5.5.3  describes  my  proposed  restrictions  to  functional  model,  and  Section  5.5.4 
derives  the  semantics  of  the  restricted  functional  model  from  the  semantics  of  generalized  data  flow 
diagrams. 

5.5.1  Overview  of  Rumbaugh’s  Functional  Model.  The  OMT  functional  model  is  defined 
using  standard  data  flow  diagrams  describing  the  computations  that  a  system  must  perform.  The 
functional  model  is  intended  to  be  used  in  conjunction  with  the  object  and  dynamic  models  to 
complete  the  system  definition.  Whereas  the  object  model  defines  system  components  and  the 
dynamic  model  defines  system  control,  the  functional  model  defines  what  computations  occur  in 
the  system.  The  functional  model  describes  what  outputs  are  derived  from  inputs,  but  not  how, 
or  in  what  order,  this  transformation  is  accomplished.  The  “how”  is  an  implementation  question 
while  the  “order”  of  the  computations  is  defined  in  the  dynamic  model. 

As  stated  above,  the  functional  model  uses  data  flow  diagrams  to  describe  what  computations 
occur  in  the  system  and  the  relationship  of  inputs  to  outputs.  Data  flow  diagrams  consist  of  four 
basic  entities:  processes,  data  flows,  data  stores,  and  actors.  Processes  transform  input  data  values 
into  output  data  values  and  are  represented  by  ovals  in  the  data  flow  diagram.  Rumbaugh  states 
that  “the  lowest-level  processes  are  pure  functions  without  side  effects”  (83:124)  while  higher-level 
processes  may  have  side  effects  such  as  modifying  data  stores  or  other  external  objects.  In  general, 
high-level  processes  represent  non-side  affecting  operations  or  actions  defined  in  the  dynamic  model. 
Each  process  may  be  decomposed  into  subprocesses  which  take  the  inputs  to  its  higher-level  process 
and  provide  a  more  detailed  description  of  the  transformations  necessary  to  produce  the  high-level 
outputs.  These  “nested”  data  flow  diagrams  require  that  all  higher-level  process  input  data  flows 
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be  present  in  the  nested  data  flow  diagram  and  that  the  outputs  of  the  higher-level  process  be 
computed  by  processes  in  the  nested  data  flow  diagram.  Eventually,  all  nested  data  flow  diagrams 
terminate  with  purely  functional  processes. 


In  the  functional  model,  data  flows  are  denoted  by  lines  drawn  between  processes  and  repre¬ 
sent  data  values  input  to,  or  output  from  a  process.  Arrows  indicate  the  direction  the  data  flows. 
A  data  flow  from  one  process  to  another  specifles  that  the  data  is  output  by  the  first  process  and 
input  to  the  second  process.  Often,  data  flows  are  “forked”  to  denote  copying  the  data  value  and 
sending  it  to  more  than  one  process  as  shown  in  Figure  5.12.  When  a  data  flow  represents  an 
aggregate  data  type,  the  data  flow  may  “split”  into  its  various  components.  Likewise,  aggregate 
components  may  be  composed  into  an  aggregate  value  by  merging  two  or  more  data  flows  into  a 
single  data  flow. 

Data  stores  are  passive  objects  in  the  system  used  to  store  data  and  are  represented  by  parallel 
lines.  Data  stores  are  usually  objects,  object  classes,  or  associations  defined  in  the  object  model. 
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(a)  Copy  (b)  Split  or  Decompose 

Figure  5.12  Data  Flows 

Data  flows  into  a  data  store  represent  modifications  to  the  stored  data  while  data  flows  out  of 
a  data  store  represent  data  retrieved  from  the  data  store.  Data  flows  with  hollow-tipped  arrows 
represent  the  dynamic  creation  of  a  new  object.  Such  arrows  flow  from  a  process  to  a  data  store 
and  are  unique  to  the  OMT  functional  model.  Figure  5.13  shows  the  use  of  data  stores  in  a  data 
flow  diagram.  In  Figure  5.13  the  Bank-Accounts  data  store  is  the  set,  or  class,  of  accounts  in  a 
bank.  The  get-account  process  chooses  an  account  based  on  an  account  number  entered  by  a  user. 
The  selected  account  then  becomes  a  data  store  and  is  manipulated  by  the  deposit  process. 


Figure  5.13  Data  Stores 


Actors  are  objects  outside  the  system  that  provide  input  to  or  consume  the  output  of  data 
flow  diagrams.  Actors  are  not  actually  part  of  the  system  and  are  not  modeled  further  in  OMT. 
Actors  are  represented  by  rectangles  and  their  inclusion  in  the  functional  model  simply  provides 
the  context  for  the  computations  defined  within. 
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Rumbaugh  also  allows  for  control  flows  within  the  functional  model.  Control  flows  are  boolean 
values  that  affect  whether  a  process  is  performed  and  are  not  input  values  to  the  process.  Control 
flows  are  denoted  by  dashed  lines  between  processes.  According  to  Rumbaugh,  control  flows  “can 
occasionally  be  useful,  but  they  duplicate  information  in  the  dynamic  model  and  should  be  used 
sparingly”  (83:129). 

5.5.2  Functional  Model  Translation  Problems.  This  section  discusses  problems  inherent 
in  translating  the  functional  model,  as  specifled  by  Rumbaugh,  into  algebraic  speciflcations.  Some 
of  these  problems  are  caused  by  translation  requirements  discussed  in  Section  5.2  while  some  are 
problems  inherent  to  data  flow  diagrams  in  general. 

The  first  problem  is  the  representation  of  actors.  Since  actors  are  only  used  to  set  the  context 
of  the  functional  model  and  do  not  affect  computations  or  data  flows  involved  in  the  model,  actor 
objects  can  be  ignored  as  long  as  all  system  inputs  and  outputs  are  accounted  for.  Therefore,  in 
the  ensuing  discussion  of  the  functional  model,  I  assume  that  actors  are  unimportant  to  translating 
the  functional  model  and  may  be  excluded. 

The  second  problem  is  Rumbaugh’s  use  of  the  functional  model.  While  he  states  that  high- 
level  processes  should  equate  to  operations  in  the  object  model  or  actions  in  the  dynamic  model, 
he  tends  to  a  take  a  system-level  view  when  developing  his  functional  model  and,  as  a  result,  his 
processes  are  unrelated  to  the  object  or  dynamic  models.  This  system-level  use  forces  the  specifler 
to  backtrack  and  attempt  to  determine  exactly  where  these  new  processes  should  reside.  However, 
if  I  stick  to  his  original  statement  that  processes  represent  operations  and  actions  and  use  the 
functional  model  only  to  decompose  non-side  affecting  operations  (i.e.,  queries)  and  previously 
deflned  actions,  this  problem  disappears  and  the  three  models  become  integrated.  While  many  of 
the  operations  and  actions  of  basic  object  classes  are  simple  enough  to  write  axiomatic  deflnitions, 
operations  and  actions  of  aggregate  objects  tend  to  require  more  thought  and  decomposition.  Thus, 
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in  this  research,  I  assume  that  only  non-side  affecting  operations  or  previously  defined  actions  are 
decomposed  using  functional  models  and  that  these  are  generally  used  at  the  aggregate  level. 

Next,  problems  associated  with  translation  requirement  7,  that  all  entities  in  the  model  must 
be  represented  by  pure  functions,  sorts,  and  first  order  axioms,  are  addressed.  Initially,  it  seems 
that  processes  may  simply  be  represented  by  functions,  data  flows  by  sorts  and  variables  in  first 
order  axioms,  and  data  stores  by  specific  values  in  the  sorts.  However,  the  first  problem  with  this 
simplistic  approach  is  the  requirement  to  use  pure  functions  to  represent  processes.  While  Rum- 
baugh  states  that  the  lowest-level  processes  are  pure  functions,  higher-level  processes  are  allowed  to 
cause  side  affects  (i.e.,  modify  other  objects,  classes  of  objects,  or  associations)  within  the  system. 
Since  algebraic  specifications  require  pure  functions  at  all  levels,  the  question  is  how  to  represent 
side  effects  in  pure  functions.  Functions  in  algebraic  specifications  may  emulate  side  affects  by 
requiring  the  object  of  interest  to  be  input  to  and  output  from  the  function.  If  I  assume  processes 
only  affect  the  objects,  object  classes,  or  associations  within  the  aggregate  for  which  they  are  being 
designed,  all  processes  may  be  defined  as  pure  functions.  Because  process  side  effects  may  only 
affect  the  current  aggregate  object,  if  the  aggregate  object  is  passed  as  an  input  parameter  to  a 
function  and  returned  as  an  output  parameter,  then  the  process  is  a  pure  function. 

The  second  problem  related  to  translation  requirement  I  involves  the  use  of  data  stores.  Since 
data  stores  represent  objects,  object  classes,  or  associations  within  the  aggregate  object,  passing 
the  aggregate  object  as  an  input  parameter  to  each  process  allows  each  processes  access  to  any 
object  within  the  aggregate.  The  process  may  modify  or  send  events  to  aggregate  components  as 
specified  and  return  their  modified  values  upon  completion.  Actually,  if  a  particular  process  only 
accesses  or  modifies  a  single  component  within  the  aggregate,  only  that  particular  component  need 
be  passed  as  a  parameter.  In  effect,  the  process  in  question  becomes  an  operation  on  the  component 
it  accesses  or  modifies. 
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The  final,  and  most  difficult,  set  of  problems  is  related  to  translation  requirement  II,  that 
all  functional  models  be  completely  deterministic.  Unfortunately,  Rumbaugh  himself  states  that 
the  functional  model  does  not  uniquely  specify  results  of  side-effecting  processes  and  shows  only 
possible  data  paths.  Basically  what  Rumbaugh  is  saying  is  that  just  because  certain  processes  and 
data  paths  are  shown  in  the  functional  model,  not  all  processes  or  data  flows  are  necessarily  used 
to  compute  the  high-level  process  outputs.  For  instance.  Figure  5.14  shows  a  functional  model  for 
a  process  update  data.  The  data  flow  diagram  at  the  bottom  depicts  the  decomposition.  The  data 
modifications  is  input  to  process  A  which  computes  two  outputs  x  and  y.  These  outputs  become 
inputs  to  processes  B  and  C  respectively.  Process  B  retrieves  a  data  value  d  from  the  Data  store 
and  updates  Data  store  with  data  d  as  well.  Process  C,  on  the  other  hand,  simply  updates  Data 
store  with  a  data  value  d.  As  Rumbaugh  states,  this  diagram  only  shows  us  possible  data  flows  and 
processes  used  to  implement  update  data.  Do  B  and  C  both  execute  and  update  different  aspects 
of  Data  store  and  does  the  order  of  their  execution  matter?  Or,  does  either  B  or  C  execute  (based 
on  a  decision  made  in  A)  and  update  Data  store?  Obviously,  the  diagram  does  not  provide  enough 
information  to  decide,  and  therefore  cannot  be  deterministically  translated  into  a  set  of  functions 
and  axioms  that  implement  update  data. 

Since  all  processes  are  required  to  be  pure  functions,  process  A  must  output  both  x  and  y 
everytime  it  is  called,  thus  requiring  some  control  feature  to  determine  when  R  or  C  is  executed. 
One  solution  is  to  require  the  sorts  for  both  x  and  y  to  provide  a  “distinguished”  value,  such  as 
undefined,  for  A  to  output  indicating  which  process  should  execute.  An  alternative  solution  is 
to  require  A  to  output  explicit  control  flow  information.  Both  of  these  choices  are  particularly 
uninspiring.  Impregnating  sorts  with  distinguished  values  to  control  execution  is  unacceptable 
as  it  inhibits  reuse  and  is  theoretically  impure  .  This  example  only  requires  the  definition  of  a 
single  distinguished  value;  however,  in  more  complex  control  situations,  additional  distinguished 
values  might  be  added  to  the  point  where  reuse  of  specifications  in  different  contexts  might  become 
unmanageable  due  to  conflicting  sort  values.  Use  of  control  flows  is  also  unacceptable  since  control 
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Figure  5.14  A  Nondeterministic  Functional  Model 
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flow  is  deflned  in  the  dynamic  model.  Use  of  additional  control  flows  in  the  functional  model  leads 


to  confusion  and  almost  certainly  inconsistent  specifications.  A  better  approach  is  to  place  all 
control  flow  information  in  the  dynamic  model  using  additional  states  and  transitions  as  shown  in 
Figure  5.15,  or  to  define  these  decisions  using  axiomatic  process  definition.  Either  solution  removes 
such  conditional  execution  and  thus  produces  a  deterministic  functional  model. 


event/update-data(modificalions) 


Figure  5.15  Placing  Control  in  Dynamic  Model 


The  final  problem  with  the  functional  model  is  a  problem  with  data  flow  diagrams  in  general: 
How  are  sequencing,  iteration,  and  conditional  execution  represented?  In  Rumbaugh’s  functional 
model  this  is  not  a  problem  since  he  allows  the  functional  model  to  represent  “possible  paths”. 
However,  as  pointed  out  above,  to  translate  the  functional  model  into  algebraic  specifications,  it 
must  be  deterministic.  Therefore,  the  sequencing/iteration/conditional  execution  problem  is  the 
same  problem  discussed  above  and  requires  the  same  solution:  specify  all  control  in  the  dynamic 
model  or  directly  using  axioms.  Sequencing,  iteration,  and  conditional  execution  can  all  be  handled 
by  either  method. 
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5.5.3  The  Restricted  OMT  Functional  Model.  To  deterministically  translate  the  func¬ 
tional  model  into  algebraic  specifications,  certain  restrictions  were  suggested  in  Section  5.5.2.  These 
suggestions  are  embodied  in  the  following  rules  and  ensure  translation  requirements  I  and  II  are 
met. 

1.  Assumption  V.8  Only  non-side  affecting  operations  (i.e.,  queries)  or  actions  (side  affecting 
operations)  defined  in  the  dynamic  model  are  decomposed  using  functional  models. 

2.  Assumption  V.9  Processes  only  affect  the  objects,  object  classes,  or  associations  within  the 
class  (aggregate)  for  which  it  is  being  designed. 

3.  Assumption  V.IO  Data  stores  must  be  class  sets  or  associations  while  data  flows  are  indi¬ 
vidual  objects  and  links.  If  a  data  store  is  a  class  set,  the  name  of  the  data  store  is  assumed 
to  be  “c-CLASS”  or  a  role  name  (where  “c”  is  the  name  of  the  class).  If  the  data  store  is  an 
association,  the  name  of  the  data  store  is  assumed  to  be  “c- ASSOC”. 

4.  Assumption  V.ll  All  processes  are  pure  functions.  All  data  stores  accessed  must  be  input 
as  parameters  to  the  process. 

5.  Assumption  V.12  All  processes  must  be  either  1)  a  method,  or  2)  a  purely  functional  op¬ 
eration: 

(a)  All  processes  implementing  dynamic  model  actions  are  assumed  to  be  side  affecting  and 
take  an  object  (and  possibly  other  parameters)  as  input  and  return  the  modified  object  as 
output. 

(b)  All  processes/subprocesses  that  access  or  modify  data  stores  must  input  the  appropriate 
class  set  or  association. 

( c)  All  processes/subprocesses  that  modify  data  stores  may  output  only  a  single  data  store 
and  thus  become  “leaf”  process  in  the  functional  model. 
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6.  Assumption  V.13  All  retrievals  from  data  stores  are  performed  by  a  “leaf”  process  that 
accesses  only  a  single  data  store.  This  retrieval  occurs  before  modifications  to  data  stores  may 


occur. 

7.  Assumption  V.14  By  convention,  data  flows  to  or  from  a  data  store  are  label  with  Kclass- 
name  :  class-set-sort>  or  <association-name  :  association- sort> . 

8.  Assumption  V.15  There  is  no  explicit  ordering  of  updates  to  the  same  data  store.  All 
sequencing  requirements  must  be  specified  in  the  dynamic  model  only. 

9.  Assumption  V.16  All  subprocesses  execute  and  produce  all  outputs  whenever  the  higher- 
level  process  is  executed. 

10.  Assumption  V,17  Conditions,  loops,  and  sequencing  requirements  are  specified  in  the  dy¬ 
namic  model  only.  Sequencing  in  the  functional  model  is  derived  solely  from  data  dependen¬ 
cies. 

11.  Assumption  V.18  All  uniquely  named  data  flows  into  or  out  of  a  process  are  individual 
inputs  or  outputs  of  the  process  and  completely  define  the  input  and  output  parameters  of  the 
process.  Data  flows  from  a  single  process  with  identical  names  and  types  are  considered  a 
single  output  and  may  be  used  as  inputs  to  multiple  processes  or  data  stores. 

12.  Assumption  V.19  Data  flows  are  represented  as  name  :  type  and  are  assumed  to  be  unique. 
If  two  identically  named  data  flows  are  outputs  from  the  same  process,  they  are  assumed  to 
be  a  single  output. 

13.  Assumption  V.20  Composition  and  decomposition  of  aggregate  values  is  performed  by  user- 
defined  processes.  Forking  and  joining  of  data  flows  is  not  supported. 

14.  Assumption  V.21  Copying  of  data  may  be  performed  by  a  specific  process  or  by  outputting 
multiple  copies  of  a  data  flow  from  a  single  process.  Copying  by  splitting  data  flows  is  not 
supported. 
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5.5.4  Functional  Model  Semantics.  In  this  section  I  formally  define  the  semantics  of  the 
restricted  OMT  functional  model.  A  few  formal  definitions  of  data  flow  diagram  semantics  have 
been  proposed.  Adler  (2)  and  Tao  (92)  propose  graph-based  semantics  with  a  relation  defining 
the  precedence,  or  “is  used  to  compute”,  relationship  that  exists  between  data  flows.  Vazquez  (94) 
defines  semantics  of  data  flow  diagrams  by  sentences  over  a  S-term  algebra,  where  S  is  an  algebraic 
signature  defining  the  basic  constructs  of  data  flow  diagrams  including  some  very  simplistic  control 
structures.  Since  control  is  not  included  in  the  restricted  functional  model,  I  choose  to  model  the 
semantics  of  data  flow  diagrams  using  the  approach  of  Tao  and  Kung.  Tao  and  Kung  formally 
define  data  flow  diagrams  as  a  directed  graph  with  a  precedence  relation  over  the  data  flows  as 
defined  below. 

Definition  5.5.1  A  Data  Flow  Diagram  is  a  quadruple  D  =  {C,F,K,R)  where 

•  C  =  PUSUE  is  a  nonempty  finite  set  of  components  consisting  of  pairwise  disjoint  sets:  P, 
the  set  of  processes;  S  the  set  of  data  stores;  and  E  the  set  of  external  entities. 

•  F  C  (P  X  P)  [J  {P  X  S)li  {S  X  P)  U  {P  X  E)  U  {E  X  P)  is  the  set  of  data  flows;  each  with  a 
unique  name. 

•  K  C  Pu  S  is  the  set  of  subsystem  components,  and  C  —  K  the  environment. 

•  RC  F  X  F  is  a  precedence  relation  between  elements  of  F. 


This  definition  defines  a  data  flow  diagram  as  a  directed  graph  with  a  set  of  components 
(processes  and  data  stores)  within  the  environment  (the  system)  being  modelled  as  well  as  outside 
the  environment  (actors)  to  set  the  diagram  “context” .  Each  data  flow  is  assumed  to  have  a  unique 
name  and  transfer  data  directly  from  one  component  to  another  (i.e.,  no  splitting  or  forking). 
Because  general  data  flow  diagrams  do  not  require  all  paths  to  be  executed,  certain  data  flow 
inputs  to  a  process  may  not  be  used  to  compute  all  outputs  of  the  process.  Thus  Tao  and  Kung 
define  a  precedence  relation  to  describe  exactly  which  inputs  are  required  to  produce  which  outputs 
as  defined  below. 

Definition  5.5.2  The  Precedence  Relation  of  a  data  flow  diagram,  D,  denoted  Rd,  is  the 
transitive  closure  of  the  union  of  the  precedence  relations  for  all  components  c  €  K,  or  Rd  = 
(U  ceK  Fc)'^  where  Rc  denotes  the  precedence  relation  for  the  component  c  and  is  the  transitive 
closure.  Rc  is  defined  as: 
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•  If  c  £  P  then  Rc  is  the  empty  sei  {}  if  P  £  C  —  K;  otherwise,  P  is  a  mapping  from  I{c)  to 
0(c)  such  that  {di,dj)  £  Rc  if  and  only  if  di  is  used  by  P  to  produce  dj. 

•  If  c  £  S  then  Rc  is  the  empty  set  {}  if  S  £  C  —  K;  otherwise,  di  £  I{c)  and  dj  £  0{c), 
{di,dj)  £  Rc  if  and  only  if  di  and  dj  contain  some  data  item  in  common. 

•  If  c£  E  then  Rc  is  the  empty  set  {}. 

where  I{c)  and  0(c)  are  the  input  to  and  outputs  from  component  C. 

The  precedence  relation  defines  precisely  which  data  fiows  must  be  defined  prior  to  the  com¬ 
putation  of  other  data  flows.  The  relation  is  defined  over  the  components  in  the  environment.  Just 
because  a  data  flow  is  an  input  to  a  process  does  not  mean  it  is  used  to  compute  a  particular 
output  of  the  same  process.  That  information  lies  solely  in  the  internal  semantics  of  the  process. 
For  example,  assume  we  have  a  process,  ProduceReports  that  produces  two  reports,  a  summary 
report  and  an  error  report,  as  shown  in  Figure  5.16.  In  this  case,  the  summary  report  is  generated 
as  long  as  there  are  valid  or  invalid  accounts  input  to  the  process  whereas  the  error  report  is  only 
generated  when  there  are  invalid  accounts  input  to  the  process.  In  this  case,  RproduceReporta  = 
{(invalid-accounts,  error-report)},  since  neither  valid  or  invalid  accounts  are  required  to  produce 
a  summary  report;  however,  an  invalid  account  is  required  to  produce  an  error  report. 


Figure  5.16  Non-Deterministic  Precedence 


Therefore,  to  define  the  precedence  relation,  the  analyst  must  know  the  functionality  of  each 
process.  That  is,  he  or  she  must  know  which  output  data  is  dependent  upon  which  input  data. 
Although  the  precedence  relation  captures  the  data  flow  relationships,  it  does  not  provide  control 
information.  For  instance,  in  Figure  5.14,  it  is  still  not  known  whether  process  B  or  C  executes,  or 
in  what  order  the  input  and  output  to  the  data  store  occur. 
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Given  the  restrictions  placed  on  general  data  flow  diagrams  in  the  restricted  OMT  functional 
model  in  Section  5.5.3,  the  semantics  of  data  flow  diagrams  as  defined  by  Tao  and  Kung  can  be 
refined  to  define  the  semantics  of  the  restricted  OMT  functional  model. 

Definition  5.5.3  A  Restricted  OMT  Functional  Model  is  a  quadruple  D  —  {C,F,K,R) 
where 

•  C  =  PliSliEisa  nonempty  finite  set  of  components  consisting  of  pairwise  disjoint  sets: 
P,  the  set  of  processes;  S  the  set  of  data  stores;  and  E  ~  {Extern}  where  Extern  represents 
any  entity  external  to  the  object  being  defined. 

•  F  C  (P  X  P)  U  {P  X  S)  Li  {S  X  P)  U  (P  X  E)  U  {E  X  P)  is  the  set  of  data  flows;  each  with  a 
unique  name. 

•  K  =  PU  S  is  the  set  of  subsystem  components. 

•  RC  F  X  F  is  a  precedence  relation  between  elements  of  F. 

Because  the  functional  model  restrictions  require  all  inputs  to  precede  all  outputs,  and  for  all 
data  store  reads  to  precede  data  store  writes,  the  precedence  relation  becomes  computable  directly 
from  C  and  F  and  requires  no  analyst  intervention. 

Definition  5.5.4  The  Precedence  Relation /or  a  restricted  OMT  functional  model,  D,  denoted 
Rd,  is  the  transitive  closure  union  of  the  precedence  relations  for  all  components  c  £  K,  or  Rd  = 
(Uc€/f  Rc  denotes  the  precedence  relation  for  the  component  c  and  +  is  the  transitive 

closure.  Rc  is  defined  as: 

•  IfcQP  then  Rc  =  {{di,  dj)  \  di  €  /(c)  A  dj  G  0(c)}. 

•  If  c  G  S  then  Rc  =  {{di,  dj)  \  di  G  I{c)  A  dj  G  0(c)}. 

•  RExtern  ~  {}• 

Thus,  for  the  restricted  functional  model,  the  precedence  relation  simply  defines  which  data 
flows  must  be  computed  before  others  based  on  their  graph  location.  With  these  semantics,  struc¬ 
tural  aspects  of  the  restricted  functional  model  are  completely  defined.  For  a  subdiagram  that 
defines  a  higher-level  process,  this  defines  the  semantics  of  the  higher-level  process  in  terms  of 
lower-level  processes.  The  internal  functionality  of  these  low-level  processes  are  defined  axiomati- 
cally. 
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5. 6  Summary 


This  report  describes  the  OMT  object  model  as  used  by  Rumbaugh  as  well  as  problems 
encountered  when  attempting  translate  it  into  algebraic  specifications.  Restrictions  and  exact 
interpretations  of  the  object  model,  dynamic  model,  and  functional  model  entities  are  presented 
which  allow  the  object  model  to  be  deterministically  translated  into  algebraic  specifications.  The 
formal  semantics  of  the  restricted  object  model  are  represented  by  Bourdeau  and  Cheng’s  algebraic 
specification,  the  semantics  of  the  restricted  dynamic  model  are  derived  from  the  semantics  of 
statecharts  as  defined  by  Harel,  while  the  semantics  of  the  restricted  functional  model  are  derived 
from  generalized  data  flow  diagram  semantics. 

The  semantics  defined  in  this  chapter  are  used  in  Chapter  VI  to  help  define  the  theory-based 
model.  Their  main  use,  however,  is  in  Chapter  VII  where  they  are  used  to  show  that  the  translations 
defined  in  that  chapter  preserve  the  semantics  of  the  individual  models. 
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VI.  A  Theory-Based  Object  Model 

6. 1  Introduction 

This  chapter  defines  a  theory-based  object  model  based  on  Rumbaugh’s  semi-formal  Object 
Modeling  Technique  (OMT)  (83).  The  theory-based  object  model  is  described  using  algebraic 
specifications  to  define  object  classes  while  relationships  between  classes  are  defined  via  category 
theory  operations  within  the  category  Spec.  The  algebraic  theory  language  used  to  capture  the 
internal  class  structure  as  well  as  the  relationships  between  classes  is  O- Slang,  an  object-oriented 
derivative  of  Slang  (54).  A  complete  description  of  0-Slang  is  contained  in  Appendix  B. 

This  theory-based  object  model  is  designed  to  faithfully  capture  the  essence  of  an  object- 
oriented  specification  in  a  formal  framework  and  to  provide  the  capability  to  reason  about  the 
resulting  specification.  This  framework  is  based  on  a  formal  definition  of  generally  accepted  object- 
oriented  concepts.  Section  6.2  presents  the  basic  concepts  of  object  classes  including  attributes, 
methods,  events,  operations,  and  states  and  how  they  are  captured  in  an  algebraic  specification. 
The  next  three  sections  discuss  relationships  between  objects  using  algebraic  class  specifications  and 
category  theory  concepts:  Section  6.3  defines  the  mechanism  and  effects  of  inheritance.  Section  6.4 
presents  the  concept  of  links  and  associations,  and  Section  6.5  discusses  a  unique  specification,  the 
aggregate  class.  The  final  section.  Section  6.6,  explains  how  event  theories  and  category  theory 
operation  are  used  to  create  communication  paths  in  a  domain  model  based  on  events  defined  in 
the  dynamic  model. 

There  are  four  basic  premises  upon  which  the  theory-based  object  model  is  based. 

1.  The  model  is  designed  to  capture  information  necessary  for  domain  modeling.  Domain  mod¬ 
eling  is  concerned  with  capturing  general  object  classes  and  operations  within  a  domain. 
System  specifications  are  derived  from  domain  models  by  selecting  the  specific  number  and 
types  of  object  classes  as  well  as  providing  detailed  system  level  requirements  as  discussed  in 
Chapter  II. 
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2.  The  two  central  concepts  of  object-orientation  are  object  classes  and  the  relationships  between 


them.  These  relationships  include  association,  generalization-specialization,  and  aggregation. 

3.  The  model  assumes  consistent  user  defined  class  specifications.  The  model  only  ensures  that 
this  consistency  is  maintained  when  composing  specifications. 

4.  All  three  Rumbaugh  models  map  into  classes  using  a  restricted  notion  of  Rumbaugh  semantics 
as  defined  in  Chapter  V.  For  instance,  Rumbaugh’s  object  model  is  used  to  define  classes 
and  their  relationships.  There  is  a  dynamic  model  for  each  class  which  defines  how  the  class 
responds  to  incoming  events  and  a  functional  model  to  define  how  aggregate  actions  are 
transformed  into  component  actions. 

6.2  Classes 

The  building  block  of  object-orientation  is  the  object  class.  There  are  two  types  of  classes: 
abstract  and  concrete.  A  concrete  class  is  a  blueprint  from  which  instances  of  the  class,  called 
objects,  are  created.  An  abstract  class  is  a  class  with  no  direct  instances  but  whose  descendents  do 
have  direct  instances  (83:61)  and  are  discussed  in  detail  in  Section  6.2.10.  Concrete  classes  have  two 
parts:  a  class  type  and  a  class  set.  Class  sets  are  discussed  in  Section  6.2.8.  A  class  type  defines  the 
structure  of  an  object  and  its  response  to  external  stimuli  based  its  current  state.  A  class  type  also 
has  two  components:  attributes  and  operations.  An  attribute  is  an  observable  characteristic  of  an 
object  and  may  either  be  constant  or  change  over  time.  Attribute  values  do  not  necessarily  uniquely 
define  individual  objects  -  two  distinct  objects  may  have  identical  attribute  values.  Although  an 
object’s  attribute  values  are  generally  accessible  to  other  objects,  modifications  of  those  values  may 
only  be  done  by  the  object  itself,  thus  providing  greater  reuse  potential.  Objects  communicate 
via  message  passing  or  through  global  events.  In  message  passing,  one  object  sends  a  message 
to  another  object.  The  message  is  then  processed  by  the  receiving  object,  possibly  causing  it  to 
change  state  or  to  send  additional  messages.  In  an  event  driven  system,  objects  generate  events 
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which  are  broadcast  globally  and  “captured”  by  other  objects  in  the  system.  In  general,  the  object 
generating  an  event  does  not  know  its  destination  nor  does  the  receiving  object  know  its  source. 

In  the  theory-based  object  model,  I  define  an  object  class  type  as  a  theory  presentation  as 
defined  in  Definition  4.2.1.  For  a  given  class  C,  S  represents  the  sorts  in  the  class  including  a  class 
sort  and  any  other  sorts  referenced  in  the  theory  while  Q  is  a  set  of  theory  operations  and  are  used 
to  represent  attributes,  operations,  methods,  and  events.  Each  of  these  is  discussed  in  detail  below. 

6.2.1  Sorts.  Sorts  are  collections  of  values.  Sorts  may  represent  conventional  data  types 
such  as  integers,  reals,  or  strings,  or  they  may  be  abstract,  representing  such  things  as  people, 
places,  or  ideas.  The  theory-based  object  model  has  two  distinguished  sort  types:  class  sorts  and 
state  sorts.  A  class  sort  is  the  set  of  all  possible  object  names  in  the  class.  Each  object  within  the 
class  has  a  unique  name  from  the  class  sort.  Objects  themselves  are  not  explicitly  represented  in 
a  class  type  or  specification:  they  are  maintained  external  to  the  class  type.  By  defining  the  class 
sort  as  a  set  of  object  names,  objects  may  be  referenced  without  having  to  maintain  multiple  copies 
of  the  object.  A  second  set  of  sorts  in  a  class  type  are  the  state  sorts.  Elements  of  a  state  sort  are 
the  individual  class  states  as  defined  in  the  dynamic  model. 

6.2.2  Attributes.  Attributes  are  visible  operations  that  take  an  object  name  and  return 
the  value  of  a  particular  characteristic  associated  with  that  object.  Attribute  operations  provide 
information  about  an  object;  they  do  not  modify  the  object  in  any  way.  State  attributes  return 
values  in  the  state  sort  representing  the  current  state  of  an  object.  There  is  generally  one  state 
attribute  per  state  sort.  Multiple  state  sorts  and  attributes  are  used  to  define  concurrent  states 
and  substates.  A  more  complete  discussion  of  state  sorts  and  state  attributes  can  be  found  in 
Section  6.2.7. 

6.2.3  Methods.  Methods  are  non-visible  operations  that  modify  an  object’s  attribute 
values  and  are  defined  by  actions  in  the  dynamic  model  or  functions  in  the  functional  model.  In 
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the  theory-based  object  model,  a  method  is  not  visible  to  external  objects.  Communication  between 
objects  is  handled  strictly  by  events.  A  method  may  modify  none,  some,  or  all  of  an  object’s  non¬ 
state  attribute  values  while  event  operations  may  only  modify  state  attributes.  Formal  parameters 
of  a  method  consist  of  an  object  name  followed  by  other  additional  parameters.  The  return  value 
of  a  method  is  the  name  of  the  object.  Although  the  name  is  unchanged,  returning  the  name 
of  the  object  allows  the  nesting  of  method  and  attribute  calls.  Generally,  the  effect  of  a  method 
on  an  object  is  defined  by  its  effect  on  each  of  the  non-state  attributes  of  the  object.  Since  the 
method  returns  the  name  of  the  object  passed  to  it,  a  method  invocation  may  be  “embedded”  in 
an  attribute  invocation  allowing  the  effect  of  the  method  on  the  attribute  to  be  precisely  specified 
as  shown  below. 

attribute-n.axo.e(Tnethod-TMTne(object-name))  =  new-value-of -attribute 

In  a  concrete  class,  it  is  assumed  that  the  effect  of  each  method  is  completely  defined  for  all 
possible  object  states  and  input  parameters. 

Assumption  VI.  1  In  a  concrete  class,  the  effect  of  each  method  on  each  normal  attribute  in  the 
class  is  completely  defined  for  all  states  and  input  parameters. 

If  the  general  result  of  a  method  applied  to  an  object  in  a  particular  state  cannot  be  computed  or 
doesn’t  make  sense  (i.e.,  divide  by  zero,  etc.),  the  effect  of  the  method  must  still  be  defined.  In 
most  cases,  if  an  object  is  in  an  inappropriate  state  prior  to  the  method  invocation  or  parameters 
passed  to  the  method  are  invalid,  there  is  simply  no  effect  on  the  object.  These  preconditions  are 
specified  easily  through  the  use  of  implication.  For  instance,  for  an  integer,  a  divide  method  only 
makes  sense  when  the  divisor  parameter  is  non-zero.  Axioms  describing  the  desired  behavior  are 
easily  specified  an  shown  below. 

parameter  7^  0  =>  value{divide{integer,parameter))  =  integer f parameter 
parameter  =  0  value{divide{integer, parameter))  =  integer 
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This  assumption  plays  an  important  role  in  defining  the  effects  of  inheritance  in  Section  6.3. 

Each  class  type  has  a  create  method  used  to  create  valid  objects  of  the  class  type.  This 
method  is  only  used  to  create  objects  and  assign  initial  values  to  attributes. 

6.2.4  Events.  Events  are  the  visible  operations  that  allow  objects  to  communicate.  Event 
operations  are  derived  from  the  dynamic  model  and  are  only  allowed  to  directly  modify  the  state 
attributes  of  a  class  as  shown  in  Figure  6.1.  As  a  side  effect,  events  may  cause  the  other  actions  to 
be  initiated.  These  actions  might  include  the  invocation  of  one  or  more  methods  or  the  generation 
of  events  to  be  sent  to  other  objects.  Each  class  type  has  a  default  new  event  which  triggers  the 
create  method  and  initializes  the  object’s  state  attributes.  Event  operations  are  discussed  in  more 
detail  in  Sections  6.3  and  6.6. 

Figure  6.1  shows  an  example  of  a  theory-based  representation  of  an  object  class  type  in  0- 
Slang.  The  operations  date,  bal,  and  acct-state  are  attributes,  create-acct,  credit  and  debit  are 
methods,  and  new-acct,  deposit  and  withdrawal  are  events. 

6.2.5  Operations.  Theory- based  object  model  Operations  are  visible  operations  that  do 
not  meet  the  criteria  of  an  attribute,  method,  or  an  event.  These  operations  are  generally  used  to 
compute  derived  attributes,  but  are  not  restricted  to  this  purpose;  however,  operations  may  not 
modify  any  of  an  object’s  attribute  values. 

A  common  example  of  a  non-derived  attribute  operation  is  attr-equal.  The  attr-equal  operation 
determines  if  two  objects  from  a  class  are  equal  based  on  the  non-state  attribute’s  values.  This 
operation  is  especially  useful  in  specifying  method  invocation  after  receipt  of  a  particular  event.  In 
this  case,  attr-equal  specifies  that  the  effect  of  a  method  on  the  non-state  attributes  is  equivalent 
to  the  effect  of  an  event  on  an  object.  In  Figure  6.1,  the  axiom 

acct-state{a)  =  ok  acct-state{deposit{a,x))  =  ok  Aattr-equal{deposit{a,x),credit{a,x)) 
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class  Acct  is 
import  Anint,  Date 
class  sort  Acct 
sorts  Acct-State 
operations 

attr-equal  :  Acct,  Acct  — ►  Boolean 
attributes 

date  :  Acct  Date 
bal  :  Acct  — >  Amnt 
state-attributes 

acct-state  :  Acct  — >  Acct-State 
methods 

create-acct  :  Date  — +  Acct 
credit,  debit  ;  Acct,  Amnt  — >  Acct 
states 

ok,  overdrawn  :  — ►  Acct-State 
events 

new-acct  :  Date  — >  Acct 
deposit,  withdrawal  :  Acct,  Amnt  Acct 
axioms 

%  state  uniqueness  and  invariant  axioms 
ok  ^  overdrawn; 

V  (a:  Acct)  acct-state(a)  =  ok  =^>  bal(a)  >  0; 

V  (a:  Acct)  acct-state(a)  =  overdrawn  ^  bal(a)  <  0; 

%  operation  definitions 

V  (a,al:  Acct)  attr-equal(a,  al)  date(a)  =  date(al)  A  bal(a)  =  bal(al); 

%  method  definitions 

V  (d:  Date)  date(create-acct(d))  =  d  A  bal(create-acct(d))  =  0; 

V  (a:  Acct,  x;  Amnt)  bal(credit(a,x))  =  bal(a)  +  x 

A  date(credit(a,x))  =  date(a)  A  rate(credit(a,x))  =  rate(a) 

A  int-date(credit(a,x))  =  int-date(a)  A  check-cost(credit(a,x))  =  check- cost  (a); 

%  event  definitions 

V  (d:  Date)  acct-state(new-acct(d))=ok  A  attr-equal(new-acct(d),  create-acct (d)) 

V  (a:  Acct,  x:  Amnt)  acct-state(a)=ok 

^  acct-state(deposit(a,x))=ok  A  attr-equal(deposit(a,x),  credit(a,x)); 

V  (a:  Acct,  x:  Amnt)  acct-state(a)=overdrawn  A  bal(a)  4-  x  >  0 

=>  acct-state(deposit(a,x))=ok  A  attr-equal(deposit(a,x),  credit(a,x)); 

V  (a:  Acct,  x:  Amnt)  acct-state(a)=overdrawn  A  bal(a)  -f  x  <  0 

=^-  acct-state(deposit(a,x))=overdrawn  A  attr-equal(deposit(a,x),  credit(a,x)); 

V  (a:  Acct,  x:  Amnt)  acct-state(a)=ok  A  bal(a)  >  x 

=>  acct-state(withdrawal(a,x))=ok  A  attr-equal(withdrawal(a,x),  debit(a,x)); 

V  (a:  Acct,  x:  Amnt)  acct-state(a)=ok  A  bal(a)  <  x 

=>  acct-state(withdrawal(a,x))=overdrawn  A  attr-equal(withdrawal(a,x),  debit(a,x)); 

V  (a:  Acct,  x:  Amnt)  acct-state(a)=overdrawn 

^  acct-state(withdrawal(a,x))=overdrawn  A  attr-equal(withdrawal(a,x),  a) 
end-class 


Figure  6.1  Object  Class 
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states  that  if  an  account  is  in  the  ok  state  and  a  deposit  event  is  received,  the  object  stays  in  the 
ok  state  and  that  the  effect  of  the  deposit  event  on  non-state  attributes  is  equivalent  to  the  effect 
of  the  credit  method  on  the  same  object. 

6.2.6  Axioms.  Class  axioms  are  first-order  logic  statements  that  must  be  true  for  any 
object  of  the  class.  They  are  used  in  class  specifications  to  define  the  semantics  of  class  operations 
as  well  as  invariants  between  class  attributes.  In  general,  axioms  define  methods  and  events  by 
describing  their  effects  on  attributes  or  through  composition  of  other  operations. 

6.2.7  State.  State  is  vital  to  object-orientation.  As  defined  by  Rumbaugh,  state  is  an  ab¬ 
straction  of  an  object’s  attribute  values  and  is  represented  by  a  statechart  in  the  dynamic  model.  A 
brief  overview  and  the  semantics  of  statecharts  are  presented  in  Section  5.4.  To  explicitly  represent 
state  in  the  theory-based  object  model,  each  class  type  has  at  least  one  state  sort  representing  this 
abstraction  of  attribute  values,  a  state  attribute  (one  for  each  state  sort)  which  returns  an  element 
from  its  associated  state  sort,  a  set  of  states  (nullary  operations)  which  are  elements  in  a  state 
sort,  and  a  set  of  state  invariants  that  describe  constraints  on  class  attributes  that  must  hold  true 
while  in  a  given  state.  State  attributes  are  only  modified  by  events  as  defined  by  transitions  in  the 
class  dynamic  model.  In  Figure  6.1,  the  class  state  sort  is  Acct-State,  the  class  state  attribute  is 
acct-state,  the  state  constants  are  ok  and  overdravm,  and  the  state  invariants  are 

acct-state(a)  =  ok  bal{a)  >  0; 
acct-state{a)  =  overdrawn  bal{a)  <  0; 

These  axioms  state  that  when  the  balance  of  an  account  is  greater  than  or  equal  to  zero,  the  account 
must  be  in  the  ok  state;  however,  when  the  balance  of  the  account  becomes  less  than  zero,  the  state 
must  become  overdrawn.  Although  not  a  state  invariant,  the  axiom 

ok  ^  overdrawn 
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is  critical  to  the  correct  interpretation  of  the  specification.  It  ensures  that  there  are  two  distinct 
states  ok  and  overdrawn.  Without  this  axiom,  a  valid  specification  model  might  have  a  single 
element  in  the  state  sort,  equivalent  to  both  ok  and  overdrawn.  Notice  that  the  specification  does 
not  restrict  the  class  state  sort  to  only  these  values.  Limiting  the  class  state  sort  to  these  values 
would  not  permit  valid  extensions  of  the  class  state  by  subclasses  as  discussed  in  Section  6.3.4. 1. 
The  effect  of  these  states  on  the  behavior  of  the  class  as  shown  in  Figure  6.2  and  is  represented  by 
the  axioms  of  the  form 

acct-atate{a)  =  ok  A  bal{a)  <  x  =>  acct-state{withdrawal{a,x))  =  overdrawn 

This  particular  axiom  requires  that  withdrawals  be  made  only  when  the  account  is  in  the  ok  state 
prior  to  the  withdrawal  event  and  that  if  the  account  is  overdrawn  as  a  result  of  a  withdrawal, 
the  new  state  of  the  account  becomes  overdrawn.  Acct  state  transitions  and  method  invocations 
defined  in  the  dynamic  model  are  defined  by  the  following  axioms. 


acct-state{a)  =  ok  ^  acct-state{deposit{a,x))  =  ok  A  attr-equal{deposit{a,x),credit{a,x))-, 
acct-state{a)  =  overdrawn  A  bal(a)  +  a:  >  0  acct-state{deposit{a,x))  =  ok 
Aattr-equal{depo3it{a,  x),  credit(a,  a:)); 

acct-state(a)  ~  overdrawn  A  bal{a)  +  a:  <  0  acct-state{deposit{a,x))  =  overdrawn 
Aattr-equal{deposit{a,  x),  credit(a,  x)); 

acct-state(a)  =  ok  A  bal{a)  >  x  ^  acct-state{wUhdrawal{a,  x))  =  ok 
Aattr-equal{withdrawal{a,x),debit{a,x)); 
acct-state{a)  =  ok  A  bal{a)  <  x  =>  acct-state{withdrawal{a,x))  =  overdrawn 
Aattr-equal  {withdrawal  (a,  x) ,  debit{a,  x)); 
acct-state{a)  =  overdrawn  =>  acct-state{withdrawal{a,x))  =  overdrawn 
Aattr-equal  {withdrawal  (a ,  x) ,  a) 


These  axioms  require  that  the  account  state  become  overdrawn  when  a  withdrawal  is  performed 
that  makes  the  account  balance  less  than  zero  and  that  the  account  state  may  only  change  back  to 
ok  when  a  deposit  is  made  making  the  balance  greater  than  or  equal  to  zero. 

Dynamic  model  statecharts  allow  concurrent  states  and  substates.  Concurrent  statecharts  are 
used  when  the  attributes  of  a  class  type  are  partitionable  into  subsets  as  discussed  in  Section  5.4.1. 
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withdrawal(a,x)  [bal(a)  >=  x]/debit(a,x) 


Figure  6.2  Account  Dynamic  Model 

Formally,  concurrent  states  are  represented  by  multiple  state  attributes,  one  for  each  concurrent 
statechart.  Substates  are  handled  similarly  to  concurrent  states  -  by  adding  additional  substate 
attributes  which  are  valid  only  when  the  class  state  attribute  is  in  the  appropriate  state.  Additional 
examples  of  using  and  specifying  concurrent  and  substates  are  described  in  Section  6.3.4. 1. 

6.2.8  Class  Set.  The  Acct  class  as  defined  in  Figure  6.1  only  specifies  a  template  for 
creating  new  objects  of  the  Acct  class.  However,  Rumbaugh’s  informal  model  implies  the  ability  to 
collectively  manage  a  set  of  objects  in  a  class.  To  provide  this  capability,  a  class  set  is  created  for 
each  class  defined  (both  abstract  and  concrete). 

Definition  6.2.1  Class  Set  -  A  class  set  is  a  class  whose  class  sort  is  a  set  of  objects  from  a 
previously  defined  object  class,  C.  A  class  set  includes  a  “class  event”  definition  for  each  event  in 
C  such  that  the  reception  of  a  class  event  by  a  class  set  object  sends  the  corresponding  event  in  C 
to  each  object  of  type  C  contained  in  the  class  set  object.  If  the  class  C  is  a  subclass  of  Di...Dn 
then  the  class  set  of  C  is  a  subclass  of  the  class  sets  o/Di...D„. 

The  class  set  creates  a  class  type  whose  class  sort  is  a  set  of  objects  and  some  basic  operations 
on  that  set.  Using  the  specifications  of  TRIV &nd  as  defined  in  Appendix  E  and  basic  category 
theory  operations,  the  class  set  can  be  derived  automatically  as  shown  in  Figure  6.3.  The  equivalent 
0-Slang  specification  is  shown  in  Figure  6.4. 
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spec  Acct-Class-Colimit  is 
colimit  of  diagram 

nodes  TRIV,  ACCT,  SET 
arcs  TRIV  —  ACCT  :  {E  —  Acct} 
TRIV  SET  :  {} 
end-diagram 

spec  Acct-Class-Set  is 

translate  ACCT-CLASS-COLIMIT 
by  {Set  — ♦  Acct-Class,  E  — >  Acct} 


spec  Acct-Class  is 
import  ACCT-CLASS-SET 
sort  Acct-Class 
operations 

new-acct-class  :  — >  Acct-Class 
withdrawal  ;  Acct-Class,  Amnt  — »  Acct-Class 
deposit  ;  Acct-Class,  Amnt  — >  Acct-Class 
axioms 

new-acct-class()  =  empty-set; 

V  (a;  Acct,  ac;  Acct-Class,  x:  Amnt)  a  €  ac  deposit(a,x)  e  deposit(ac,x); 

V  (a:  Acct,  ac;  Acct-Class,  x:  Amnt)  a  €  ac  withdrawal(a,x)  g  withdrawed(ac,x) 

end-class 

Figure  6.3  Slang  Class  Set  Specification 


class  Acct-Class  is 
contained-class  ACCT 
class  sort  Acct-Class 
events 

new-acct-class  :  — >  Acct-Class 
withdrawal  :  Acct-Class,  Amnt  —*  Acct-Class 
deposit  :  Acct-Class,  Amnt  — >  Acct-Class 
axioms 

new-acct-class  0  =  empty-set; 

V  (a:  Acct,  ac:  Acct-Class,  x:  Amnt)  a  g  ac  deposit(a,x)  g  deposit(ac,x); 

V  (a;  Acct,  ac:  Acct-Class,  x:  Amnt)  a  g  ac  withdrawaJ(a,x)  g  withdrawal(ac,x) 

end-class 


Figure  6.4  0-Slang  Class  Set  Specification 
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The  specification  ACCT-CLASS-COLIMIT creates  a  new  specification  using  the  sort  Ein  the 
specification  SET  as  a  formal  parameter  and  instantiating  it  using  the  specification  TRIV,  unifying 
sort  E  in  SET  with  the  class  sort  Acct  from  the  ACCT  class.  The  diagram  for  this  operation  is 
shown  in  Figure  6.5. 


Acct-Class-Set 


Acct-Class 

Figure  6.5  Colimit  of  Accounts 

The  colimit  of  TRIV,  SET,  and  ACCT  results  in  an  intermediate  specification  with  a  set  of 
account  objects  named  Set.  To  eliminate  ambiguity,  the  intermediate  specification  is  translated  in 
the  ACCT-CLASS-SET  specification  such  that  the  sort  S'et  translates  to  Acct-Class  and  the  sort  Eis 
translated  to  Acct.  The  renaming  of  E  eliminates  the  sort  name  equivalence  class  {E,  Acct}  created 
by  the  colimit  operation  while  the  renaming  of  Set  creates  the  class  sort  of  the  final  specification 
ACCT-CLASS. 

ACCT-CLASS  imports  the  ACCT-CLASS-SET  specification  (and  with  it  the  ACCT  class 
type  definition)  in  order  to  add  additional  “class”  events.  These  class  events  mirror  the  individual 
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“object”  events  defined  in  the  class  type  specification.  Class  set  specifications  simply  distribute 
the  event  invocation  to  each  object  currently  contained  in  the  class  set.  Additional  operations  for 
selecting  individual  objects  from  the  class  set  based  on  class  attributes  may  also  be  specified  by  the 
designer  using  an  aggregate  or  association  qualifier.  Use  of  qualifiers  is  discussed  in  Section  6.4.2 
and  6.5.2. 

6.2.9  Object-Valued  Attributes.  As  discussed  in  Section  6.2,  each  object  within  the  class 
has  a  unique  name  which  allows  other  objects  (including  itself)  to  reference  it.  Object-Valued 
attributes  are  the  mechanism  used  to  reference  external  objects  from  within  a  class  type  definition 
and  are  the  key  to  formally  modeling  association  and  aggregation.  An  object-valued  attribute  is  a 
class  attribute  whose  sort  type  is  a  set  of  object  names  (a  class  set  sort).  Object- valued  attributes 
behave  like  normal  class  attributes.  Formally,  they  are  specification  operations  that  take  an  object 
name  and  return  an  external  object  name  or  set  of  names. 

The  effects  of  methods  on  object-valued  attributes  are  defined  similarly  to  normal  attributes. 
However,  instead  of  directly  specifying  a  new  value  for  the  object-valued  attribute,  an  event  from 
the  object-valued  attribute’s  class  is  sent  to  the  object  named  by  the  object-valued  attribute. 

An  example  of  using  an  object-valued  attribute  is  shown  in  Figure  6.6.  In  this  example. 
Producer  is  a  class  of  objects  which  produce  items  to  be  stored  in  a  buffer.  Buffer  is  a  class  of 
simple  buffer  objects  with  get  and  put  operations.  The  attribute  buffer-obj  is  an  object-valued 
attribute  which  holds  the  name  of  the  specific  buffer  object  in  which  the  producer  object  stores  its 
items.  Once  the  producer  and  buffer  are  initialized,  each  produce-item  event  invokes  the  produce 
method  which  causes  the  item  produced  by  the  producer  to  be  put  into  the  buffer  referenced  by 
the  buffer  object- valued  attribute  as  defined  by  the  following  axiom. 

buf  fer-obj{jproduce{p,i))  =  put{buffer-obj{p),  i) 

The  put  event  is  made  available  by  importing  the  Buffer  class  type  specification  directly  into 
the  Producer  specification.  It  is  important  to  note  that  all  modifications  of  objects  referenced 
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by  object-valued  attributes  are  accomplished  by  sending  events  to  the  objects  instead  of  directly 
invoking  methods  since  events  ensure  the  object  is  in  the  appropriate  state  before  a  method  is 
invoked.  A  direct  method  invocation  could  result  in  errors  or  inconsistencies  in  the  referenced 
object. 


class  Producer  is 
imports  Buffer,  Item 
class  sort  Producer 
sorts  Producer-State 
operations 

attr-equal  :  Producer,  Producer  — »  Boolean 
attributes 

buffer-obj  :  Producer  — >  Buffer 
methods 

create-producer  :  Buffer  — >  Producer 

produce  :  Producer,  Item  — ►  Producer 
events 

new-producer  :  Buffer  — >  Producer 

produce-item  ;  Producer,  Item  Producer 
axioms 

%  operation  definitions 

V  (p,pl:  Producer)  attr-equal(p,  pi)  =^-  buffer-obj(p)  =  buffer-obj  (pi); 

%  event  definitions 

V  (b;  Buffer)  attr-equal(new-producer(b),  create-producer(b)); 

V  (i:  Item,  p:  Producer)  attr-equal(produce-item(p,i),  produce(p,i)); 

%  method  definitions 

V  (b:  Buffer)  buffer-obj  (create-producer(b))  =  b; 

V  (i:  Item,  p:  Producer)  buffer-obj(produce(p,i))  =  put(buffer-obj(p),i) 
end-class 


Figure  6.6  Object- Valued  Attribute  Example 


6.2.10  Abstract  Classes.  Abstract  classes  and  concrete  classes  are  defined  in  the  same 
manner  with  one  exception.  Because  abstract  classes  are  not  instantiable,  they  are  not  required  to 
fully  define  operations  and  thus  Assumption  VI.l  does  not  hold.  Basically  this  allows  specification 
operations  (methods  or  operations)  to  be  defined  without  fully  defining  their  effect  on  every  at¬ 
tribute.  Only  characteristics  that  must  hold  true  in  all  subclasses  need  be  specified.  If  an  operation 
is  not  completely  defined,  it  is  called  an  abstract  operation.  Abstract  classes  are  generally  used  to 
abstract  out  common  elements  of  subclasses  without  having  to  fully  define  them. 
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6.3  Inheritance 


In  this  research,  inheritance  holds  to  the  substitution  property  as  presented  in  Section  4.4. 
Simple  inheritance  is  modelled  using  specifications  morphisms  between  class  specifications  as  de¬ 
fined  in  Definition  4.4.2  while  multiple  inheritance  is  defined  in  Defintion  4.4.3. 

As  discussed  in  Section  4.2.1,  showing  that  a  group  of  first  order  axioms  are  consistent  is 
generally  not  possible;  however,  since  by  Assumption  I.l  user  defined  specifications  are  consistent, 
I  can  develop  rules  to  ensure  this  consistency  is  not  violated  when  inheritance  is  applied.  Because 
methods  and  events  are  defined  in  terms  of  their  affect  on  attributes,  these  rules  are  developed 
based  on  the  effect  of  methods  and  events  on  attributes.  Table  6.1  shows  the  rules  for  methods  and 
normal  attributes.  Basically  this  tables  shows  that  in  a  subclass,  new  axioms  may  not  be  generated 
that  define  how  a  method  defined  in  the  superclass  affects  an  attribute  defined  in  the  superclass. 


Table  6.1  Method/ Attribute  Inheritance  Rules 


Method  defined  in 

Attribute  defined  in 

Validity  of  axiomatic  definition 
in  subclass  of 

effect  of  method  on  attribute 

Superclass 

Superclass 

Invalid 

Superclass 

Subclass 

Valid 

Subclass 

Superclass 

Valid 

Subclass 

Subclass 

Valid 

Because,  by  Assumption  VI.l,  superclass  methods  are  completely  defined  over  superclass 
attributes,  additional  axioms  are  not  needed  and  can  only  lead  to  inconsistencies  in  the  subclass. 
Notice  that  the  other  three  combinations  are  valid.  In  fact,  the  other  three  combinations  are 
required  to  ensure  that  methods  introduced  in  the  subclass  and  superclass  are  completely  defined 
over  attributes  introduced  in  both  the  superclass  and  subclass.  These  same  rules  hold  for  events  and 
state  attributes  as  well;  however,  additional  rules  for  substates  and  concurrent  states  are  developed 
in  Section  6.3.4.I. 

An  example  of  single  inheritance  using  a  subclass  of  the  ACCT  class,  SACCT  -  a  savings 
account  class,  is  shown  in  Figure  6.7.  The  import  statement  includes  all  the  sorts,  operations. 
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and  axioms  declared  in  the  ACCT  class  directly  into  the  new  class  while  the  class  sort  declaration 
SAcct  <  Acct  states  that  SAcct  is  a  subsort  of  Acct,  and  as  such,  all  operations  and  axioms 
that  apply  to  an  Acct  object  apply  to  a  SAcct  object  as  well.  The  dynamic  model  for  SACCT  is 
shown  in  Figure  6.8.  The  import  operation  defines  a  specification  morphism  between  ACCT  and 
5^  e'er  while  the  subsort  declaration  completes  the  requirements  of  Definition  4.4.2  for  inheritance. 
Therefore,  SACCT  is  a  valid  subclass  of  ACCT,  the  substitution  property  holds,  and  internal  class 
consistency  is  preserved. 

6.3.1  Implications  of  the  Substitution  Property.  Since  my  interpretation  of  the  substitu¬ 
tion  property  defined  in  Equation  4.3  implies  that  a  subclass  D  must  only  act  like  its  superclass 
in  an  environment  design  specifically  for  the  superclass,  it  is  possible  for  a  subclass  to  have  states 
in  which  it  does  not  behave  like  its  superclass.  The  substitution  property  only  requires  that  these 
new  states  not  be  reachable  via  events  available  to  the  superclass.  Consider  the  example  shown  in 
Figure  6.9.  The  statechart  in  Figure  6.9(b)  extends  the  statechart  in  Figure  6.9(a)  by  adding  a  new 
state.  A  subclass  object  behaves  like  an  object  from  its  superclass  as  long  as  event  e4  sending  the 
object  from  state  3  to  state  4  is  not  received.  Once  in  state  4,  the  subclass  no  longer  behaves  like  a 
member  of  the  superclass.  While  definitely  not  wrong,  this  effect  may  not  satisfy  one’s  intuition  of 
what  is  expected  in  a  subclass  -  superclass  relationship.  The  more  restrictive  interpretation  given 
by  Bourdeau  and  Cheng  (14),  as  discussed  in  Section  4.4,  forces  a  subclass  object  to  reside  only  in 
states  defined  in  the  superclass  object  and  thus  would  not  allow  state  4  to  be  added  in  the  subclass. 

6.3.2  Multiple  Inheritance.  Multiple  inheritance  is  defined  in  Definition  4.4.2.  To  create 
an  account  that  combines  the  features  of  a  savings  account  with  those  of  a  checking  account, 
CACCT  (Figures  6.10  and  6.11),  the  colimit  of  classes  ACCT,  SACCT,  CACCT,  and  morphisms 
from  ACCT  to  SACCT  and  CACCT  is  computed  as  shown  in  Figure  6.12,  where  an  arrow  labeled 
with  an  “i”  represents  an  import  morphism  and  a  “c”  represents  a  morphism  formed  by  the  colimit 
operation.  A  simple  extension  of  the  colimit  specification  with  the  class  sort  definition 
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class  SAcct  is 
import  Acct,  Rate 
class  sort  SAcct  <  Acct 
operations 

attr-equal  :  SAcct,  SAcct  — ►  Boolean 
attributes 

rate  :  SAcct  Rate 
int-date  :  SAcct  —>■  Date 
methods 

create-sacct  :  Date  — >  SAcct 
set-rate  :  SAcct,  Date,  Rate  — >  SAcct 
comp-int  :  SAcct,  Date  SAcct 
events 

new-sacct  :  Date  — »  SAcct 
rate-change  :  SAcct,  Date,  Rate  — >  SAcct 
compute-interest  :  SAcct,  Date  — »  SAcct 
axioms  V  (d:  Date,  r:  Rate,  a,  al:  SAcct) 

%  operation  definitions 

V  (a,al:  SAcct)  attr-equal(a,  al)  ^  rate(a)  =  rate(al)  A  int-date(a)  =  int-date(al); 

%  create  method  definition 

V  (d:  Date)  date(create-sacct(d))  =  date(create-acct(d))  A  bal(create-sacct(d))  =  bal(create-acct(d)) 
A  acct-state(create-sacct(d))  =  acct-state(create-acct(d))  A  int-date(create-sacct(d))  =  d 

A  rate(create-sacct(d))  =  0; 

%  credit  method  definitions 

V  (s:  SAcct,  a:  Amnt)  rate(credit(s,a))  =  rate(s)  A  int-date(credit(s,a))  =  int-date(s); 

%  debit  method  definitions 

V  (s;  SAcct,  a:  Amnt)  rate(debit(s,a))  =  rate(s)  A  int-date{debit(s,a))  =  int-date(s); 

%  set-rate  method  definitions 

V  (d:  Date,  r:  Rate,  a:  SAcct)  rate(set-rate(a,d,r))  =  r  A  int-date(set-rate(a,d,r))  =  d 
A  bal(set-rate(a,d,r))  =  bal(a)  A  date(set-rate(a,d,r))  =  date(a); 

%  comp-int  method  definitions 

V  (d;  Date,  a:  SAcct)  rate(comp-int(a,d))  =  rate(a)  A  int-date(comp-int(a,d))  =  d 

A  bal(a)  >  0  bal(comp-int(a,d))  =  bal(a)  -f  rate(a)  *  ((d  -  int-date(a))/days-per-year(d)) 

A  bal(a)  <  0  bal(comp-int(a,d))  =  bal(a)  A  date(comp-int(a,d))  =  date(a); 

%  new  event  definition 

V  (d:  Date)  acct-state(new-sacct(d))  =  ok  A  attr-equal(new-sacct(d),  create-sacct(d)); 

%  rate-change  event  definitions 

V  (d:  Date,  r:  Rate,  a:  SAcct)  acct-state(a)  =  ok  =?►  acct-state(rate-change(a,d,r))  =  ok 
A  attr-equal(rate-change(a,d,r),set-rate(comp-int(a,d),d,r)); 

V  (d:  Date,  r:  Rate,  a:  SAcct)  acct-state(a)  =  overdrawn 
=>  acct-state(rate-change(a,d,r))  =  overdrawn 

A  attr-equal(rate-change(a,d,r),set-rate(comp-int(a,d),d,r)); 

%  compute-interest  event  definitions 

V  (d;  Date,  a:  SAcct)  acct-state(a)  =  ok  ^  acct-state(compute-interest(a,d))  =  ok 
A  attr-equal(compute-interest(a,d),comp-int(a,d)); 

V  (d:  Date,  a:  SAcct)  acct-state(a)  =  overdrawn  =>  acct-state(compute-interest(a,d))  =  overdrawn 
A  attr-equal(compute-interest(a,d),a) 

end-class 


Figure  6.7  Savings  Class 
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deposit(a,x)/credit(a,x) 


Figure  6.8  Savings  Account  Dynamic  Model 


(a)  Superclass  state  model 


(b)  Subclass  state  model 


Figure  6.9  Subclass  State  Extension 


Comb-Acct  <  SAcct,  CAcct 


yields  the  desired  class  where  Comb-Acct  is  a  subclass  of  both  SAcct  and  CAcct.  Figures  6.13,  6.14, 
and  6.15  show  the  “long”  version  of  the  combined  specification  with  all  the  attributes,  methods, 
and  events  inherited  by  the  Comb-Acct  class. 


6.3.3  Subclasses  and  Class  Sort  Subsorts.  The  subclass  -  superclass  relationship  corre¬ 
sponds  to  the  subsort  -  supersort  relationship  of  the  class  sort.  Since  a  subclass  has  all  the  features 
of  the  superclass  and  subclass  object  can  be  substituted  for  superclass  objects,  it  subclass  objects 
are  in  fact,  members  of  the  superclass.  Since  there  is  a  one-to-one  correspondence  between  objects 
in  a  class  and  names  in  the  class  sort,  an  object  in  a  subclass  must  have  a  name  in  the  subsort  as 
well  as  in  the  class  sort. 

The  0-Slang  subsort  operator  <  defines  a  subset  relationship  among  sorts  such  that  for  two 
sorts,  A  and  B  in  specification  S,  A  <  B  ^  A'  C  B'  where  A'  and  B'  are  sets  representing  A 
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class  CAcct  is 

import  Acct  class  sort  CAcct  <  Acct 
operations 

attr-equal  :  CAcct,  CAcct  — »  Boolean 
attributes 

check-cost  :  CAcct  Amnt 
methods 

create-cacct  :  Date  — »  CAcct 
set-check-cost  ;  CAcct,  Amnt  — *  CAcct 
events 

new-cacct  :  Date  — ►  CAcct 
change-check-cost  :  CAcct,  Amnt  — >  CAcct 
write-check  :  CAcct,  Amnt  — »  CAcct 
axioms  V  (a:  CAcct,  x:  Amnt) 

%  operation  definitions 

attr-equal(a,  al)  =>  check-cost(a)  =  check-cost (al); 

%  create  method  definition 
date(create-cacct(d))  =  date(create-acct(d)); 
bal(create-cacct(d))  =  bal(create-acct(d)); 
acct-state(create-cacct(d))  =  acct-state(create-acct(d)); 
check-cost(create-cacct(d))  =  0; 

%  credit  method  definitions 

V  (c:  CAcct,  a;  Amnt)  check-cost(credit(c,a))  =  check-cost(c); 

%  debit  method  definitions 

V  (c:  CAcct,  a;  Amnt)  check-cost(debit(c,a))  =  check-cost(c); 

%  set-check-cost  method  definition 

V  (a:  CAcct,  x;  Amnt)  check-cost(set-check-cost(a,  x))  =  x; 

%  new  event  definition 

V  (d:  Date)  acct-state(new-cacct(d))  =  ok  A  attr-equal(new-cacct(d),  create-acct(d)); 

%  write-check-cost  event  definition 

V  (a:  CAcct,  x:  Amnt)  acct-state(a)  =  ok  A  bal(a)  >  x 

=>  acct-state(write-check(a,x))  =  ok  A  attr-equal(write-check(a,x),  debit(a,x); 

V  (a:  CAcct,  x:  Amnt)  acct-state(a)  =  ok  A  bal(a)  <  x 

=>  acct-state(write-check(a,x))  =  overdrawn  A  attr-equal(write-check(a,x),  debit(a,x); 

V  (a:  CAcct,  x:  Amnt)  acct-state(a)  =  overdrawn 

=>  acct-state(write-check(a,x))  =  overdrawn  A  attr-equal(write-check(a,x),  debit(a,x); 

%  set-check-cost  method  definition 

V  (a:  CAcct,  x:  Amnt)  acct-state(a)  =  ok 

=>  acct-state(write-check(a,x))  =  ok  A  attr-equal(change-check-cost(a,x),  set-check-cost(a,x))  ; 

V  (a:  CAcct,  x:  Amnt)  acct-state(a)  =  overdrawn 

=>  acct-state(write-check(a,x))  =  overdrawn  A  attr-equal(change-check-cost(a,x),  set-check-cost (a,x)) 
end-class 


Figure  6.10  Checking  Class 
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withdrawal(a,x)  [bal(a)  >=  x]/debit(a,x) 


change-cheol<-oost(a,x)^ 

/set-check-cost(a,x) 

new-cacct(d) _ 


write-checl<(a,x) 

[bal(a)  >=  x+check-cost(a)] 
/debit(a,x+check-cost(a)) 


writ6-check(a,x) 


change-check-cost(a,x) 

/set-check-cost(a,x) 


deposit(a,x)/credlt(a,x) 


deposit(a,x)  [x  +  bal(a)  <  0] 
/credit(a,x) 


write-oheok(a,x)/debit(a,x,+cheok-oost{a)) 


Figure  6.11  Checking  Account  Dynamic  Model 
Acct 


Comb-Acct 

Figure  6.12  Colimit  of  Accounts 


and  B  in  a  model  of  S.  Thus,  if  a  class  D  is  a  subclass  of  a  class  C,  then  the  class  sort  of  D,  Dcs, 
is  a  subsort  of  the  class  sort  of  class  C,  Ccs,  or  C  C7'^. 


6.3.4  Behavioral  Inheritance.  There  are  two  methods  of  behavioral  specification  in  OMT: 
the  dynamic  model  and  the  functional  model.  Dynamic  behavior  is  specified  by  a  statechart  for 
each  class  while  functional  behavior  is  specified  at  the  system,  or  aggregate  level  by  data  flow 
diagrams.  Section  6. 3. 4.1  defines  the  effects  of  inheritance  on  the  dynamic  model  while  Section 
6. 3.4. 2  describes  the  effects  of  inheritance  of  functional  behavior. 


6.3.4. 1  Dynamic  Inheritance.  Because  the  effect  of  a  method  or  event  is  based 
on  the  object’s  state  and  must  be  equivalent  to  the  effect  of  a  method  or  event  on  a  superclass 
object,  modification  of  inherited  dynamic  behavior  must  conform  to  certain  rules.  Since  each  class 
has  possibly  multiple  “state” ,  “substate” ,  or  “concurrent  state”  attributes  (as  described  in  Section 
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class  Comb-Acct  is 

import  SAcct,  CAcct 

class  sort  Comb-Acct  <  SAcct,  CAcct 

sorts  Acct-State 

operations 

attr-equal  :  Comb-Acct,  Comb-Acct  — ♦  Boolean 
attributes 

date  :  Comb-Acct  — ►  Date 
bal  ;  Comb-Acct  — ♦  Amnt 
rate  :  Comb-Acct  — ►  Rate 
int-date  ;  Comb-Acct  — >  Date 
check-cost  :  Comb-Acct  Amnt 
state-attributes 

acct-state  :  Comb-Acct  — »  Acct-State 
methods 

create-acct  ;  Date  — ♦  Comb-Acct 
create-sacct  :  Date  — ♦  Comb-Acct 
create-cacct  :  Date  -+  Comb-Acct 
create-comb-acct :  Date  -+  Comb-Acct 
credit  ;  Comb-Acct,  Amnt  — ♦  Comb-Acct 
debit  :  Comb-Acct,  Amnt  — »  Comb-Acct 
set-rate  :  Comb-Acct,  Date,  Rate  —*  Comb-Acct 
int  ;  Comb-Acct,  Date  — +  Comb-Acct 
set-check-cost  :  Comb-Acct,  Amnt  — ♦  Comb-Acct 
write-check  :  Comb-Acct,  Amnt  — <•  Comb-Acct 
states 

ok  :  — ►  Acct-State 
overdrawn  :  — »  Acct-State 
events 

new-acct  :  Date  —*■  Comb-Acct 

new-sacct  :  Date  — ►  Comb-Acct 

new-cacct  :  Date  Comb-Acct 

new-comb-acct :  Date  —>■  Comb-Acct 

deposit  :  Comb-Acct,  Amnt  Comb-Acct 

withdrawal  :  Comb-Acct,  Amnt  — >  Comb-Acct 

rate-change  :  Comb-Acct,  Date,  Rate  —>■  Comb-Acct 

compute-interest  :  Comb-Acct,  Date  — ►  Comb-Acct 

change- check- cost  :  Comb-Acct,  Amnt  — >  Comb-Acct 

write-check  ;  Comb-Acct,  Amnt  — *•  Comb-Acct 

Figure  6.13  Combined  Account  Signature 
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axioms 

%  state  uniqueness  and  invariant  axioms 
ok  ^  overdrawn; 

V  (a:  Acct)  acct-state(a)  =  ok  =>  bal(a)  >  0; 

V  (a:  Acct)  acct-state(a)  =  overdrawn  bal(a)  <  0; 

%  operation  definitions 

V  (a,al:  Acct)  attr-equal(a,  al)  date(a)  =  date(al)  A  bal(a)  =  bal(al); 

V  (a,al:  SAcct)  attr-equal(a,  al)  =>■  rate(a)  =  rate(al)  A  int-date(a)  =  int-date(al); 

V  (a,al:  CAcct)  attr-equaJ(a,  al)  check-cost(a)  =  check-cost  (al); 

%  create-acct  method  definition 

V  (d:  Date)  date(create-acct(d))  =  d  A  bal(create-acct(d))  =  0; 

%  create-sacct  method  definition 

V  (d:  Date)  date(create-sacct(d))  =  date(create-ax;ct(d)) 

wedge  bal(create-sacct(d))  =  bal(create-acct(d))  wedge  rate(create-sacct(d))  =  0 
wedge  int-date(create-sacct(d))  =  d; 

%  create-cacct  method  definition 

V  (d:  Date)  date(create-cacct(d))  =  date(create-acct(d)) 

A  bal(create-cacct(d))  =  bal(create-acct(d))  A  check-cost(create-cacct(d))  =  0; 

%  create-comb-cacct  method  definition 

V  (d:  Date)  date(create-comb-acct(d))  =  date(create-acct(d)) 

wedge  bal(create-coinb-acct(d))  =  bal(create-acct(d))  wedge  rate(create-comb-acct(d)) 
wedge  int-date(create-comb-acct(d))  =  d  A  check-cost(create-comb-acct(d))  =  0; 

%  credit  method  definition 

V  (a:  Acct,  x;  Amnt)  bal(credit(a,x))  =  bal(a)  -I-  x 

A  date(credit(a,x))  =  date(a)  A  rate(credit(a,x))  =  rate(a) 

A  int-date(credit(a,x))  =  int-date(a)  A  check-cost(credit{a,x))  =  check-cost  (a); 

%  debit  method  definitions 

V  (a:  Acct,  x:  Amnt)  bal(debit(a,x))  =  bal(a)  -  x 

A  date(debit(a,x))  =  date(a)  A  rate(debit(a,x))  =  rate(a) 

A  int-date(debit(a,x))  =  int-date(a)  A  check-cost(debit(a,x))  =  check-cost(a); 

%  set-rate  method  definitions 

V  (a:  Acct,  d:  Date,  r:  Rate)  rate(set-rate(a,d,r))  =  r 

A  int-date(set-rate(a,d,r))  =  d  A  bal(set-rate(a,d,r))  =  bal(a) 

A  date(set-rate(a,d,r))  =  date(a); 

%  comp-int  method  definitions 

V  (a:  Acct,  d:  Date)  rate(comp-int(a,d))  =  rate(a) 

A  int-date(comp-int(a,d))  =  d  A  date(comp-int(a,d))  =  date(a); 

V  (a:  Acct,  d:  Date)  bal(a)  <  0  =>  bal(comp-int(a,d))  =  bal(a); 

V  (a:  Acct,  d:  Date)  bal(a)  >  0  bal(comp-int(a,d))  =  bal(a) 

-I-  rate(a)  *  ((d  -  int-date(a))/days-per-year(d)); 

%  set-check-cost  method  definition 

V  (a;  Acct,  x:  Amnt)  check-cost(set-check-cost(a,  x))  =  x 

A  bal(set-check-cost(a,x))  =  bal(a)  A  data(set-check-cost(a,x)  =  date(a) 


Figure  6.14  Combined  Account  Class  Axioms 
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%  new  event  definition 

V  (d:  Date)  acct-state(new-acct(d))  =  ok  A  attr-equal(new-acct(d),  create-acct(d)); 

V  (d:  Date)  acct-state(new-sacct(d))  =  ok  A  attr-equal(new-sacct(d),  create-sacct(d)); 

V  (d:  Date)  acct-state(new-cacct(d))  =  ok  A  attr-equal(new-cacct(d),  create-cacct(d)); 

V  (d:  Date)  acct-state(new-comb-acct(d))  =  ok  A  attr-equal(new-comb-acct(d),  create-comb-acct(d)) 
%  deposit  event  definition 

V  (a:  Acct,  x:  Amnt)  acct-state(a)  =  ok  acct-state(deposit(a,x))  =  ok 
A  attr-equal(deposit(a,x),  credit(a,x)); 

V  (a:  Acct,  x;  Amnt)  acct-state(a)  =  overdrawn  A  bal(a)  +  x  >  0 

acct-state(deposit(a,x))  =  ok  A  attr-equal(deposit(a,x),  credit(a,x)); 

V  (a:  Acct,  x:  Amnt)  acct-state(a)  =  overdrawn  A  bal(a)  +  x  <  0 

acct-state(deposit(a,x))  =  overdrawn  A  attr-equal(deposit(a,x),  credit(a,x)); 

%  withdrawal  event  definition 

V  (a:  Acct,  x;  Amnt)  acct-state(a)  =  ok  A  bal(a)  >  x 

acct-state(withdrawal(a,x))  =  ok  A  attr-equal(withdrawal(a,x),  debit(a,x)); 

V  (a:  Acct,  x;  Amnt)  acct-state(a)  =  ok  A  bal(a)  <  x 

=i-  acct-state(withdrawal(a,x))  =  overdrawn  A  attr-equal(withdrawal(a,x),  debit(a,x)); 

V  (a;  Acct,  x:  Amnt)  acct-state(a)  =  overdrawn 

acct-state(withdrawal(a,x))  =  overdrawn  A  attr-equal(withdrawal(a,x),  a); 

%  rate-change  event  definitions 

V  (a:  Acct,  d;  Date,  r;  Rate)  acct-state(a)  =  ok 

acct-state(rate-change(a,d,r))  =  ok  A  attr-equal(rate-change(a,d,r),set-rate(comp-int(a,d),d,r)); 

V  (a;  Acct,  d;  Date,  r:  Rate)  acct-state(a)  =  overdrawn 
=J>  acct-state(rate-change(a,d,r))  =  overdrawn 

A  attr-equal(rate-change(a,d,r),set-rate(comp-int(a,d),d,r)); 

%  compute-interest  event  definitions 

V  (a;  Acct,  d:  Date)  acct-state(a)  =  ok 

=^-  acct-state(compute-interest(a,d))  =  ok  A  attr-equal(compute-interest(a,d),comp-int(a,d)); 

V  (a:  Acct,  d:  Date)  acct-state(a)  =  overdrawn 

^  acct-state(compute-interest(a,d))  =  overdrawn  A  attr-equal(compute-interest(a,d),a); 

%  write-check-cost  event  definition 

V  (a:  Acct,  x:  Amnt)  acct-state(a)  =  ok 

A  bal(a)  >  x  =>  acct-state(write-check(a,x))  =  ok 
A  attr-equal(write-check(a,x),  debit(a,x)); 

V  (a:  Acct,  x:  Amnt)  acct-state(a)  =  ok 

A  bal(a)  <  x  =>  acct-state(write-check(a,x))  =  overdrawn 
A  attr-equal(write-check(a,x),  debit(a,x)); 

V  (a;  Acct,  x:  Amnt)  acct-state(a)  =  overdrawn 

acct-state(write-check(a,x))  =  overdrawn  A  attr-equal(write-check(a,x),  debit(a,x)); 

%  set- check- cost  method  definition 

V  (a:  Acct,  x:  Amnt)  acct-state(a)  =  ok 

^  acct-state(write-check(a,x))  =  ok  A  attr-equal(change-check-cost(a,x),  set-check-cost (a,x))  ; 

V  (a;  Acct,  x:  Amnt)  acct-state(a)  =  overdrawn 
=4-  acct-state(write-check(a,x))  =  overdrawn 

A  attr-equal(change-check-cost(a,x),  set-check-cost(a,x)) 
end- class 


Figure  6.15  Combined  Account  Class  Axioms  (Continued) 
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6.2)  that  explicitly  capture  its  defining  statecharts,  the  requirements  of  the  substitution  property 
(Equation  4.3)  apply  to  dynamic  behavior  and  are  captured  in  the  specification  morphism  require¬ 
ment  for  inheritance.  Figures  6.16  through  6.20  show  examples  of  how  a  Rumbaugh  statechart 
may,  and  may  not  be  modified. 

ei 


Figure  6.16  Superclass  Dynamic  Behavior 


Figure  6.16  shows  the  statechart  for  a  superclass,  C.  This  statechart  translates  into  the 
following  axioms. 


state{o)  =  1  state(el(o))  =  2 
state(o)  =  1  state{e2{o))  =  1 
state{o)  =  1  =>■  state{eZ{o))  =  1 
state(o)  =  2  ^  state{el{o))  =  2 
state{o)  =  2  =?•  state{e2{o))  =  3 
state{o)  =  2  =»  state{e3{o))  =  2 
state{o)  =  3  state{el{o))  =  3 
state{o)  =  3  =>  state{e2{o))  =  3 
state{o)  =  3  s<ate(e3(o))  =  2 


Figure  6.17  Inheritance  of  Dynamic  Behavior  -  State  Extension 


To  be  valid,  the  subclass  statechart  must  translate  into  a  set  of  axioms  that  incorporate  the 
axioms  of  its  superclass  (i.e.,  the  axioms  from  the  superclass  must  be  theorems  in  the  subclass). 
Figure  6.17  shows  the  statechart  for  a  valid  subclass,  Cs,  of  the  superclass  C.  This  statechart 
translates  to  the  following  axioms.  (NOTE:  Prom  this  point  forward  in  this  section,  cixioms  defining 
no  change  are  omitted  for  brevity.) 
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state{o)  =  1  =»  3tate{el(o))  =  2 
atate(p)  =  2  state{e2{p))  =  3 
stateip)  =  3  stote(e3(o))  =  2 
state{6)  =  3  state{eA{o))  =  4 
state{o)  =  4  ^  atate(e5(o))  =  3 


To  determine  if  Cb  is  a  valid  subclass  of  C,  the  axioms  of  C  must  appear  as  theorems  in  Cb  and 
the  internal  class  consistency  conditions  must  hold.  Clearly,  the  axioms  of  C  are  theorems  in  Cb 
since  each  axiom  in  C  appears  as  an  axiom  in  Cb-  Note  that,  as  shown  in  Figure  4.7,  it  is  possible 
to  add  axioms  that  are  inconsistent.  However,  in  this  case,  there  are  no  inconsistent  axioms  and 
thus  Cb  is  a  valid  subclass  of  C. 


Figure  6.18  Inheritance  of  Dynamic  Behavior  -  Illegal 

Figure  6.18  shows  the  statechart  for  an  invalid  subclass,  Cc,  of  the  superclass  C.  This  state- 
chart  translates  to  the  following  axioms: 

atate{o)  =  1=>  atate{el{o))  =  2 
3tate{o)  =  2  =>•  3tate{e2{o))  =  3 
3tate{o)  =  3  atate{e3{o))  =  1 

Clearly  class  Cc  is  not  a  valid  subclass  of  C  since  the  axioms  of  C  are  not  theorems  in  Cc-  For 
valid  inheritance,  there  must  be  a  specification  morphism  from  the  superclass  to  the  subclass  such 
that  the  axioms  in  the  superclass  are  theorems  in  the  subclass.  If  such  a  morphism  existed  in  this 
case,  the  following  axioms  must  both  true  in  Cc- 

3tate{o)  =  3  3tate{e3{o))  =  2{fro'mCc) 

3tate{o)  =  3  =>■  3tate{e3{o))  =  l{fromC) 
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Obviously,  the  two  axioms  are  conflicting  unless  state  1  and  state  2  are  equivalent.  However,  as  part 
of  the  translation  process,  axioms  are  generated  which  specify  the  uniqueness  of  states.  Therefore 
the  axioms  of  C  are  not  theorems  in  Cc  and,  therefore,  Cc  is  not  a  valid  subclass  of  C.  To  ensure 
class  consistency,  extension  of  the  statechart  may  not  allow  new  transitions  from  a  state  defined 
in  the  superclass  using  events  defined  in  the  superclass.  This  rule  is  analogous  to  not  allowing 
superclass  methods  to  modify  superclass  attributes  as  shown  in  Table  6.1. 


Figure  6.19  Inheritance  of  Dynamic  Behavior  -  SubState  Statechart 


Figure  6.19  shows  the  statechart  for  a  valid  subclass,  Cd,  of  the  superclass  C  this  time  refined 
using  substates.  This  statechart  translates  to  the  following  axioms: 

state(o)  =  1  state{el{o))  =  2  A  svhstate2(el{o))  =  2o 
state(o)  =  3  =^*  s<ate(e3(o))  =  2  A  substate2{e3{o))  =  2o 
state{o)  =  2  =>■  state(e2{o))  =  3 

state{o)  =  2  A  substate2{o)  =  2a  state{eA{o))  =  2  A  substate2{eA{o))  =  2b 

state{6)  =  2  A  substate2{o)  =  26  =>  state{e5{o))  =  2  A  substate2{eb{p))  =  2c 

atate{6)  =  2  A  substate2{p)  =  2c=>  state{e6{o))  =  2  A  3ubstate2{e6{o))  =  2a 

Although  the  post-conditions  describing  the  effect  of  events  el  and  e3  have  changed  in  Cd,  the 
axioms  from  C  can  be  derived  from  those  in  Cd]  thus  the  axioms  of  C  are  theorems  in  Cd-  Since 
there  are  no  inconsistent  axioms,  the  internal  class  consistency  conditions  hold  and  Cd  is  a  valid 
subclass  of  C.  It  is  important  to  note  that  the  only  time  a  substate  attribute  affects  the  behavior 
of  an  object  is  when  the  object  is  in  state  2  and  that  if  event  e2  is  applied  any  time  the  state  of  a 
Cd  object  is  in  state  2,  regardless  of  the  substate,  the  state  transitions  to  3  as  required  by  C. 

In  general,  substates  can  be  used  freely  to  refine  a  superclass  statechart  as  long  as  superclass 
events  which  cause  transitions  from  the  superstate  are  not  used  within  the  substate  statechart  (i.e.. 
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the  superstate  exit  transition  is  not  overridden).  Attempting  to  override  an  exiting  transition  from 
the  superstate  results  in  inconsistent  axioms  as  shown  by  the  axioms  below  which  are  the  result  of 
replacing  event  e6  by  e2  in  Figure  6.19. 

stateip)  =  2  state{e2{o))  =  3 

state(o)  =  2  A  substate2(o}  =  2c  =>  state(e2(o))  =  2  A  substate2(e4(o))  =  2a 


Obviously,  both  axioms  cannot  be  true  since  state(e2(o))  cannot  be  both  2  and  3  simultaneously. 
Note  that  this  interpretation  of  the  statechart  does  not  satisfy  the  intent  of  such  a  statechart  as 
defined  by  Rumbaugh  (83:97).  According  to  Rumbaugh,  the  intent  of  such  a  statechart  would  be 
to  override  the  effect  of  event  e2  when  in  state  2c;  however,  if  the  axioms  implemented  Rumbaugh 
intended  semantics,  the  statechart  would  violate  the  substitution  property. 


Figure  6.20  Inheritance  of  Dynamic  Behavior  -  Concurrent  Statechart 

Figure  6.20  shows  the  statechart  for  a  valid  subclass,  Cg,  of  the  superclass  C,  this  time  refined 
using  concurrent  states.  This  statechart  translates  to  the  following  axioms. 


3tate{o)  =  1  =>■  state{el{o))  =  2 
state(o)  =  2  ^  state(e2(o))  =  3 
state(o)  =  3  ^  state{e3{o))  =  2 
conc-state{6)  =  4  =t-  conc-state{e4{o))  =  5 
conc-atate{o)  =  b  =>  conc-3tate{e5{o))  —  6 
conc-3tate{o)  —  &=>  conc-state{eb{o))  =  4 


In  this  example,  Cg,  as  defined  by  Figure  6.20,  is  a  valid  subclass  since  only  new  states  and 
events  are  used  in  the  concurrent  statechart.  However,  not  all  concurrent  statecharts  satisfy  class 
consistency  conditions.  Concurrent  statecharts  are  intended  to  be  used  when  the  attributes  of  a 
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class  are  partitionable  into  distinct  subsets.  If  class  attributes  are  paritionable,  then  the  actions  of 
each  concurrent  component  may  only  affect  attributes  in  a  single  partition.  When  this  is  not  the 
case,  inconsistencies  between  the  statechart  components  may  result.  Therefore,  when  the  dynamic 
model  is  extended  in  a  subclass  by  a  concurrent  statechart,  the  actions  of  the  concurrent  statechart 
component  must  modify  only  the  attributes  defined  in  the  subclass.  This  implies  that  only  methods 
defined  in  the  subclass  may  be  used  in  a  subclass  concurrent  statechart  component  and  that  those 
methods  may  not  modify  attributes  defined  in  the  superclass. 

In  terms  of  statecharts,  then,  the  substitution  property  requires  that  superclass  dynamic 
model  be  included,  as  is,  into  all  subclass  dynamic  models.  Additions  to  the  superclass  statechart, 
including  substates  and  concurrent  states,  that  do  not  violate  class  consistency  conditions  are  the 
only  allowable  extensions  that  satisfy  the  substitution  property. 

6. 3.4-2  Functional  Inheritance.  The  second  type  of  behavioral  inheritance  involves 
inheritance  of  the  functional  model.  In  general,  functions  define  how  data  is  transformed  in  the 
system  without  regard  to  when  these  transformations  take  place  (83).  Functions  defined  in  the 
functional  model  correspond  to  actions  defined  in  the  dynamic  model  and  are  generally  modeled 
at  the  aggregate  level.  Inheritance  from  an  abstract  class  often  allows  the  subclass  the  freedom  to 
define  the  actions  specified  in  its  dynamic  model.  In  the  case  of  an  abstract  operation,  there  is 
no  functional  definition  or  constraints  put  on  the  function  of  the  operation  in  the  abstract  class; 
therefore,  specialization  of  such  an  operation  in  a  concrete  class  must  include  its  complete  functional 
definition. 

In  the  case  of  inheritance  from  concrete  classes,  the  functional  behavior  (as  defined  by  meth¬ 
ods)  is  completely  defined  in  the  superclass.  This  greatly  restricts  the  ability  to  specialize  these 
functions  in  subclasses;  however,  this  is  not  a  problem  since  overriding  of  function  behavior  is  not 
allowed  by  the  definition  of  inheritance  and  overriding  for  other  reasons  (efiiciency,  etc.)  is  purely 
a  design  issue  and  not  important  in  domain  modeling.  Therefore,  the  only  real  way  to  functionally 
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specialize  a  subclass  is  to  add  new  functions  in  the  subclass  or  to  specify  the  effects  of  existing 
superclass  functions  on  new  subclass  attributes.  These  new  functions  would  be  derived  from  new 
actions  defined  in  the  dynamic  model  and  only  need  axiomatic  definition  in  the  functional  model. 
New  data  flow  diagrams  may  be  developed  to  further  define  the  actions,  or,  if  simple  enough,  ax¬ 
ioms  may  be  written  directly  to  define  the  action  as  a  method.  For  example,  the  dynamic  model  for 
the  savings  account  class  (Figure  6.8)  identifies  two  new  actions:  int  and  set-rate.  The  definition 
of  these  actions  are  relatively  simple  and  defined  without  the  need  for  a  new  data  flow  diagram, 
as  shown  in  Figure  6.7.  More  complex  actions  might  require  new  data  flow  diagrams  which  would 
generate  additional  methods  to  help  compute  the  defined  actions. 

Introducing  new  attributes  in  a  subclass  requires  the  extending  existing  superclass  methods 
definitions  to  include  their  effect  on  the  subclass  attributes.  As  long  as  the  requirements  specified 
in  Table  6.1  are  followed,  class  consistency  is  maintained. 

6-4  Associations 

Rumbaugh  defines  a  link  as  a  physical  or  conceptual  connection  between  object  instances 
while  an  association  is  a  group  of  links  with  a  common  structure  and  semantics  (83).  The  rela¬ 
tionship  between  associations  and  links  is  similar  to  the  relationship  between  classes  and  objects. 
In  this  model,  a  link  defines  what  object  classes  may  be  connected  along  with  any  link  attributes, 
operations,  or  qualifiers.  Link  attributes  and  link  operations  are  attributes  and  operations  that  do 
not  belong  to  any  one  of  the  objects  involved  in  a  link,  but  exist  only  when  there  is  a  link  between 
objects.  An  association  qualifier  is  an  attribute  that  is  used  to  select  an  associated  object  based 
on  the  value  of  the  qualifier.  Often,  a  qualifier  is  used  to  reduce  a  one-to-many  association  to  a 
one-to-one  association  based  on  the  qualifier  value. 

In  this  model,  associations  are  represented  generically,  as  a  specification  that  defines  a  sets 
of  individual  links.  A  link  defines  a  specification  that  uses  object-valued  attributes  to  reference 
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individual  objects  from  two  or  more  classes.  Links  may  also  define  link  attributes,  operations,  or 
qualifiers  in  a  manner  identical  to  object  classes.  Basically,  a  link  is  a  class  whose  class-set  is  an 
association. 

Definition  6.4.1  Link  A  link  is  an  object  class  type  with  two  or  more  object-valued  attributes. 

An  example  of  a  link  specification  between  a  class  of  customers  (Figure  6.21)  and  the  ACCT 
class  is  shown  in  Figure  6.22.  To  improve  reusability  and  maintainability,  integration  of  account 
numbers  or  references  directly  into  the  associated  classes  is  not  desired.  Therefore,  a  link  specifica¬ 
tion,  CA-Link,  is  created  to  associate  customers  with  their  accounts.  The  CA-LinkYiak  specification 
has  two  object-valued  attributes,  customer  and  acct,  and  a  method  to  create  new  instances  of  the 
association.  Thus,  the  CA-Link  link  specification  can  relate  objects  from  the  two  classes  without 
embedding  internal  references  into  the  classes  themselves.  Although  the  names  of  the  object-valued 
attributes  and  sorts  correspond  to  the  CUSTOMER  and  ACCT  classes,  the  link  specification  does 
not  formally  tie  the  classes  together.  This  relationship  is  actually  formalized  in  an  aggregate  spec¬ 
ification  as  defined  in  Section  6.5. 

An  associations  is  a  set  of  links  and  is  represented  as  such  in  this  model. 

Definition  6.4.2  Association  An  association  is  the  class  set  of  a  link  specification. 

An  association  between  the  ACCT  class  and  the  CUSTOMER  class  is  shown  in  Figure  6.23. 
The  CA-LINK  class  has  two  object-valued  attributes,  customer  and  account,  and  a  method  to 
create  new  instances  of  the  association.  The  CUST-ACCT  class  defines  a  set  of  CA-Link  objects 
while  its  axioms  define  the  multiplicity  relationships  between  accounts  and  customers.  In  this  case, 
there  is  exactly  one  customer  per  account  while  each  customer  may  have  one  or  more  accounts. 
Associations  with  more  than  two  classes  are  handled  in  a  similar  manner  by  simply  adding  additional 
object- valued  attributes. 
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class  Customer  is 
import  Name,  Address,  Cust-No 
class  sort  Customer 
operations 

attr-equal  :  Customer,  Customer  — >  Boolean 
attributes 

name  :  Customer  — *  Name 
address  :  Customer  — »  Address 
cust-no  :  Customer  — »  Cust-No 
methods 

create-customer  :  Name,  Address,  Cust-No  — »  Customer 
update  :  Customer,  Name,  Address,  Cust-No  — *  Customer 
events 

new-customer  ;  Name,  Address,  Cust-No  — »  Customer 
update-customer  :  Customer,  Name,  Address  — +  Customer 
axioms 

%  operation  definition 

V  (c,cl;  Customer)  attr-equal(c,cl)  ^  name(c)  =  name(cl) 

A  address(c)  =  address(cl)  A  cust-no(c)  =  cust-no(cl); 

%  create  method  definition 

V  (n:  Name,  a:  Address,  cn:  Cust-No) 
name(create-customer(n,a,cn))  =  n  A  address(create-customer(n,a,cn)) 
A  cust-no(create-customer(n,a,cn))  =  cn; 

%  update  method  definition 

V  (c:  Customer,  n:  Name,  a:  Address,  cn:  Cust-No) 
name(update(c,n,a,cn))  =  n  A  address(update(c,n,a,cn))  =  a 
A  cust-no(update(c,n,a,cn))  =  cn; 

%  new  event  definition 

V  (n:  Name,  a:  Address,  cn:  Cust-No) 
attr-equaI(new-customer(n,a,cn),  create-customer(n,a,cn)); 

%  update- customer  event  definition 

V  (c:  Customer,  n:  Name,  a:  Address,  cn:  Cust-No) 
attr-equal(update-customer(c,n,a,cn),  update(c,n,a,cn)) 

end-class 


Figure  6.21  Customer  Class 
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link  CA-Link  is 
class  sort  CA-Link 
sorts  Customer,  Account 
operations 

attr-equal  :  CA-Link,  CA-Link  — *  Boolean 
attributes 

customer  ;  CA-Link  — ♦  Customer 

account  :  CA-Link  — »  Account 
methods 

create-ca-link  :  Customer,  Account  — »  CA-Link 
events 

new-ca-link  ;  Customer,  Account  — >  CA-Link 
axioms 

%  operation  definition 

V  (c,cl;  Customer) 

attr-equal(c,cl)  customer(c)  =  customer(cl)  A  account(c)  =  account(cl); 

%  create  method  definition 

V  (c:  Customer,  a:  Account) 

customer(create-ca-link(c,a))  =  c  A  account(create-ca-link(c,a))  =  a; 

%  new  event  definition 

V  (c:  Customer,  a:  Account) 
attr-equal(new-ca-link(c,a),  create-ca-link(c,a)) 

end-link 


Figure  6.22  Customer  Account  Link 


association  CuST-AccT  is 
link-class  CA-Link 
class  sort  Cust-Acct 
sorts  Accounts,  Customers 
methods 

image  :  Cust-Acct,  Customer  Accounts 

image  :  Cust-Acct,  Account  — >  Customers 
events 

new-cust-acct  :  —>■  Cust-Acct 
axioms 

%  multiplicity  axioms 

V  (ca:  Cust-Acct,  c:  Customer)  size(image(ca,  c))  >  1; 

V  (ca:  Cust-Acct,  a:  Account)  size(image(ca,  a))  =  1; 

%  new  event  definition 

new-cust-acct  0  =  empty-set; 

...  definition  of  image  operations  ... 
end-association 

Figure  6.23  Cust-Acct  Association 
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6.4-1  Multiplicity.  For  binary  associations,  there  are  five  categories  of  association  mul¬ 
tiplicities:  exactly  one,  many,  optional,  one  or  more,  or  numerically  specified.  Since  multiplicities 
are  based  on  the  number  of  links  of  an  association  in  which  any  given  object  may  participate  in,  an 
image  operation  is  defined  for  each  class  in  the  association.  Basically,  in  a  binary  association,  the 
image  operation  returns  a  set  of  objects  with  which  a  particular  object  is  associated  and  is  used  to 
define  multiplicity  constraints  as  shown  in  Figure  6.24. 


exactly  one  size(image(a,o))  =  1 

many  size(image(a,o))  >  0 

optional  size(image(a,o))  =  1  V  size(image(a,o))  =  0 

one  or  more  size(image(a,o))  >  1 

numerically  specified  size(image(a,o))  =  x 

numerically  specified  size(image(a,o))  >  x  A  size(image(a,o))  <  y 

Figure  6.24  Association  Multiplicity  Axioms 


True  ternary  associations  are  relatively  rare;  however,  they  can  be  modeled  using  an  asso¬ 
ciation  class.  The  only  differences  between  binary  and  ternary  associations  are  the  number  of 
object-valued  attributes  and  the  signature  of  the  image  operation.  In  a  ternary  association,  the 
image  operation  returns  a  set  of  object  tuples  associated  with  a  given  object.  Since  the  output  is 
a  set  of  tuples,  the  same  multiplicity  axioms  shown  in  Figure  6.24  apply  to  ternary  association  as 
well. 


6.4-2  Qualified  Associations.  Qualifiers  are  special  attributes  used  to  reduce  the  multi¬ 
plicity  of  a  binary  association,  generally  from  one-to-many  to  one-to-one.  A  qualifier  distinguishes 
among  a  set,  or  class,  of  objects.  For  instance,  a  customer  at  a  bank  may  own  many  accounts. 
This  is  a  one-to-many  association.  However,  if  the  owns  association  is  modeled  with  an  account 
number  qualifier  as  shown  in  Figure  6.25,  the  association  becomes  one-to-one  since  each  account 
has  a  unique  account  number. 

In  the  theory-based  object  model,  qualifiers  are  modeled  as  link  attributes  with  a  qualified 
image  operation  that  selects  associated  objects  based  on  an  object  and  a  qualifier.  Again,  the 
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Figure  6.25  Association  Qualifier 


multiplicity  axioms  defined  in  Figure  6.24  can  be  used  to  restrict  the  qualified  association  using  the 
qualified  image  operation. 

An  example  of  a  qualified  account  association  is  shown  in  Figures  6.26  and  6.27.  The  CA- 
Link  specification  includes  the  qualifier  acct-no  as  an  link  attribute.  Therefore,  to  create  a  new 
link,  a  customer,  account,  and  account  number  must  be  provided.  The  Cust-Acct  association  is 
modified  by  adding  the  acct-no  qualifier  to  the  customer  image  operation.  Thus,  as  stated  by  the 
axiom  size(image(ca,c,n))  =  1,  the  multiplicity  of  the  association  is  changed  from  one-to-many  to 
one-to-one. 


link  CA-Link  is 

class  sort  CA-Link 

sorts  Customer,  Account,  Acct-No 

operations 

attr-equal  :  CA-Link,  CA-Link  — »  Boolean 
attributes 

customer  :  CA-Link  — >  Customer 

account  :  CA-Link  —*  Account 

acct-no  :  CA-Link  — »  Acct-No 
methods 

create-ca-link  :  Customer,  Account  CA-Link 
events 

new-ca-link  :  Customer,  Account,  Acct-No  — ►  CA-Link 
axioms 

%  operation  definition 

V  (c,cl:  Customer) 

attr-equal(c,cl)  -«■  customer(c)  =  customer(cl)  A  account(c)  =  account(cl) 
acct-no(c)  =  acct-no(cl); 

%  create  method  definition 

V  (c:  Customer,  a:  Account,  n;  Acct-No) 
customer(create-ca-link(c,a,n))  =  c  A  account{create-ca-link(c,a,n))  =  a 
acct-no(new-ca-link(c,a,n))  =  n; 

%  new  event  definition 

V  (c:  Customer,  a:  Account) 
attr-equal(new-ca-link(c,a),  create-ca-link(c,a)) 

end-link 


Figure  6.26  Qualified  Customer  Account  Link 
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association  Cust-Acct  is 
link-class  CA-Link 
class  sort  Cust-Acct 
sorts  Accounts,  Customers 
methods 

image  :  Cust-Acct,  Customer,  Acct-No  —*■  Accounts 
image  :  Cust-Acct,  Customer  Accounts 
image  :  Cust-Acct,  Account  Customers 
events 

new-cust-acct  :  —*  Cust-Acct 
axioms 

%  multiplicity  axioms 

V  (ca;  Cust-Acct,  c:  Customer,  an:  Acct-No)  size{image(ca,c,an))  =  1; 

V  (ca;  Cust-Acct,  a:  Account)  size(image(ca,a))  =  1; 

%  new  event  definition 

new-cust-acct()  =  empty-set; 

...  definition  of  image  operations  ... 
end-association 

Figure  6.27  Qualified  Cust-Acct  Association 


6.5  Aggregation 

Aggregation  is  another  concept  central  to  object-orientation.  Aggregation  is  a  relationship 
between  two  classes  where  one  class,  the  aggregate,  represents  the  entire  assembly  and  the  other 
class,  the  component,  is  “part-of”  the  assembly.  Aggregate  class  behavior  is  defined  by  its  com¬ 
ponents  and  the  associations  and  constraints  between  them.  Without  aggregate  objects,  a  system 
composed  of  multiple  subsystems  cannot  be  modeled.  Components  may  or  may  not  exist  apart 
from  an  aggregate  and  may  be  members  of  several  aggregates.  Aggregates  may  have  fixed,  vari¬ 
able,  or  a  recursive  structure  (83:59).  In  a  fixed  aggregate,  the  type  and  number  of  components 
are  always  the  same.  For  example,  a  car  has  one  body,  four  wheels,  one  engine,  etc.  In  a  variable 
aggregate,  the  type  of  components  in  the  aggregate  are  fixed  but  the  number  of  components  vary. 
For  instance,  in  the  banking  example,  a  bank  may  consist  of  a  number  of  employees,  customers, 
and  bank  accounts.  While  each  bank  has  employees,  customers,  and  accounts,  the  number  of  each 
component  varies  with  time  and  between  banks.  Finally,  in  the  recursive  aggregate,  components 
may  be  defined  as  aggregates  made  up  of  additional  components  of  the  same  type.  For  example, 
in  a  computer  program,  the  program  is  made  up  of  one  or  more  program  blocks.  Program  blocks 
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consist  of  statements.  Statements  may  be  simple  or  complex,  where  complex  statements  consist  of 
at  least  one  program  block. 

Not  only  do  aggregate  classes  allow  the  modeling  of  systems  from  components,  but  they  also 
provide  a  convenient  context  in  which  to  place  constraints  between  components.  For  example, 
although  the  object- valued  attributes  in  CA-Link  are  named  customer  and  account  (Figure  6.23), 
they  are  unified  with  the  CUSTOMER  and  ACCT  classes.  Unification  of  these  sorts  with  the  ap¬ 
propriate  class  sorts  requires  a  higher-level  specification  that  describes  how  classes  and  associations 
interact.  This  higher-level  specification  is  an  aggregate  class.  Once  again,  object-valued  attributes 
describe  this  relationship  between  aggregate  classes  and  their  components.  I  now  formally  define 
an  aggregate  using  the  colimit  operation  and  object-valued  attributes. 

Definition  6.5.1  Aggregate  -  A  class  C  is  an  aggregate  of  a  collection  of  component  classes, 
(Di-Dn),  if  there  exists  a  specification  morphism  from  the  colimit  of  {Di..D„)  to  C  such  that  C 
has  at  least  one  corresponding  object-valued  attribute  for  each  class  sort  in  (Di..D„). 

An  aggregate  class  combines  a  number  of  classes  via  the  colimit  operation  to  specify  system 
or  subsystem  level  functionality.  The  colimit  operation  also  unifies  sorts  and  operations  defined  in 
separate  classes  and  associations. 

To  create  system-level  aggregates,  the  colimit  of  all  classes  and  associations  within  the  system 
is  taken.  In  the  bank  account  example,  the  CUSTOMER,  ACCT,  and  CUST-ACCT  classes  are 
combined  to  form  an  aggregate  system.  To  integrate  the  components  into  an  aggregate,  the  sorts 
from  CUST  and  CUST-ACCT  and  the  sorts  from  ACCT  and  CUST-ACCT  are  unified  via  specifi¬ 
cation  morphisms  that  define  their  equivalence  as  shown  in  Figure  6.28.  The  actual  specification  of 
the  aggregation  colimit  is  shown  in  Figures  6.29  and  6.30.  The  SET  specification  is  used  to  unify 
sorts  while  the  INTEGER  specification  (Appendix  E)  is  included  to  ensure  only  a  single  copy  of 
integers  is  included.  Because  each  class  imports  the  SET  specification  (Appendix  E)  which  in  turn 
imports  the  INTEGER  specification,  failure  to  include  the  INTEGER  specification  in  the  colimit 
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would  create  a  unique  copy  of  INTEGER  for  each  class  in  the  aggregate.  Three  copies  of  the  SET 


specification  are  included  in  the  colimit  operation  since  each  class  is  defined  as  a  unique  set  and 
cannot  be  unified  with  the  other  class  sets  or  associations  defined  in  the  colimit. 


Integer 


{E  CA-Link, 

{E  ->  Acct,  \  Set  -» Cust-Acct}/ 

Set  -*  Acct-Class} 


{E  Account, 
Set  -» Accounts} 


Acct-Class 


{E  Customer, 
Set  Cust-Class} 


{E  ->  Customer, 
Set  -♦  Customers) 


Cust-Acct 


Cust-Class 


Bank 


Figure  6.28  Aggregation  Composition 


aggregate  BANK- AGGREGATE  is 

nodes  INTEGER,  SET-1:  SET,  SET-2:  SET,  SET-3:  SET, 
ACCT-CLASS,  CUST-CLASS,  CUST-ACCT 
arcs  SET-1  — +  ACCT-CLASS  :  {E  — ♦  Acct,  SET  -+  Acct-Class), 
SET-1  — »  CUST-ACCT  :  {E  —*  Account,  SET  — >  Accounts), 
SET-2  CUST-CLASS  :  {E  -»  Customer,  SET  Cust-Class), 
SET-2  — *  CUST-ACCT  :  {E  -+  Customer,  SET  —>  Customers), 
SET-3  CUST-ACCT  :  {E  CA-Link,  SET  Cust-Acct), 
INTEGER  SET-1  :  {}, 

INTEGER  SET-2  :  {} 

INTEGER  —  SET-3  :  {} 
end-aggregate 


Figure  6.29  Aggregation  Specification 


Once  the  BANK-AGGREGATE  specification  is  computed,  the  GUST-ACCT  association  ac¬ 
tually  associates  the  CUSTOMER  class  to  the  ACCT  class.  New  operations  and  axioms  can  be 
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class  Bank  is 

import  BANK-AGGREGATE 
class  sort  Bank 
attributes 

acct-obj  :  Bank  Acct-Class 
cust-obj  :  Bank  -*  Gust-Class 
cust-acct-assoc  :  Bank  — >  Cust-Acct 
methods 

aggregate  methods  defined  here 
events 

aggregate  events  defined  here 
axioms 

definition  of  aggregate  methods  in  terms  of  components  here 
size(a)  >  1; 
size(c)  >  1; 
size(ca)  >  1 

end-class 


Figure  6.30  Aggregate  Specification 


added  to  an  extension  of  colimit  specification,  the  BANK  class  type  specification  (Figure  6.30),  to 
describe  aggregate-level  interfaces  and  aggregate  behavior  based  on  component  events  and  methods. 


6.5.1  Specification  of  Components.  As  stated  above,  components  have  either  a  fixed, 
variable,  or  recursive  structure.  All  three  structures  use  object- valued  attributes  to  reference  other 
objects  and  define  the  aggregate.  The  difference  between  them  lies  in  the  types  of  objects  that 
are  referenced  and  the  operations  and  axioms  defined  over  object-valued  attributes.  In  a  fixed 
configuration,  once  an  aggregate  references  a  particular  object,  that  reference  may  not  be  changed. 
The  ability  of  an  aggregate  object  to  change  the  object  references  of  its  object- valued  attributes  is 
determined  by  whether  a  method  exists  (other  than  the  initialization  method)  to  modify  the  object¬ 
valued  attribute.  If  no  methods  modify  any  object-valued  attributes  then  the  aggregate  is  fixed.  If 
methods  do  modify  the  object-valued  attributes,  then  the  aggregate  is  variable.  An  example  of  a 
fixed  configuration  aggregate  is  the  PRODUCER  class  as  defined  in  Figure  6.6.  In  this  example,  the 
component,  buffer,  is  defined  at  initialization  and  cannot  be  changed.  Although  axioms  defining  the 
effect  of  the  method  produce  on  the  attribute  buffer-ohj  appears  to  modify  the  value  of  buffer-obj, 
they,  in  fact,  do  not.  The  axioms  simply  send  events  to  the  buffer  object  which  modify  its  internal 
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state.  An  example  of  a  variable  version  of  the  PRODUCER  class  is  shown  in  Figure  6.31.  In  this 
example,  the  method  change-buf  changes  the  object  reference  value  of  buffer-obj. 

class  Producer  is 
imports  Buffer,  Item 
class  sort  Producer 
sorts  Producer-State 
operations 

attr-equal  :  Producer,  Producer  — »  Boolean 
attributes 

buffer-obj  ;  Producer  —>■  Buffer 
methods 

create-producer  :  Buffer  — >  Producer 
produce  ;  Producer,  Item  — >  Producer 
change-buf  :  Producer,  Buffer  — »  Producer 
events 

new-producer  :  Buffer  — >  Producer 
produce-item  ;  Producer,  Item  — >  Producer 
change-buffer  :  Producer,  Buffer  —>■  Producer 
axioms 

%  operation  definitions 

V  (p,pl:  Producer)  attr-equal(p,  pi)  ^  buffer-obj(p)  =  buffer-obj(pl); 

%  event  definitions 

V  (b:  Buffer)  attr-equal(new-producer(b),  create-producer(b)); 

V  (i:  Item,  p:  Producer)  attr-equal(produce-item(p,i),  produce(p,i)); 

V  (p:  Producer,  b:  Buffer)  attr-equal(change-buffer(p,b),  change-buf(p,b)); 

%  method  definitions 

V  (b:  Buffer)  buffer-obj  (create-producer(b))  =  b; 

V  (i:  Item,  p:  Producer)  buffer-obj(produce(p,i))  =  put  (buffer-obj  (p),i); 

V  (b:  Buffer,  p:  Producer)  buffer-obj(change-buf(p,b))  =  b 
end-class 


Figure  6.31  Object- Valued  Attribute  Example 


A  recursive  structure  is  also  easily  represented  using  object- valued  attributes.  In  this  case,  an 
object-valued  attribute  is  defined  in  the  class  type  that  references  its  own  class  sort.  For  example,  a 
machine  may  consist  of  a  number  of  assemblies.  Assemblies  can  be  composed  from  individual  parts 
and  other  subassemblies,  which  in  turn  can  be  composed  of  parts  and  subassemblies,  etc.  In  this 
case,  the  machine  class  type  has  one  object-valued  attribute,  assembly-set-obj,  which  references 
a  set  of  assembly  objects.  The  assembly  class  type  definition  has  two  object-valued  attributes: 
a  parts-set-obj  which  references  a  set  of  parts,  and  an  assembly-set-obj,  which  references  a  set  of 
assembly  objects.  There  are  no  inconsistencies  with  a  recursive  aggregate  as  long  as  the  references 
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are  not  cyclic.  Cyclic  references  are  easily  avoided  via  axiomatic  specification  as  defined  below  for 
some  class  X. 

operations 

non-cydic  :  X,X  —y  boolean 

eixioms  ,  . 

y(x,y  :  X)non-cydic(x,x-obj(x)y,  (a)  ^  ' 

V(x,  y  :  X)non-cydic(x,  y)  =>  x^y,  (6) 

V(x,  y  :  X)non-cydic{x,  y)  ^  non-cydic{x,  x-obj{y))\  (c) 

These  axioms  define  a  non-cydic  operation  which  determines  if  a  cycle  exists  in  a  self- 
referencing  class  type  X.  Axiom  (a)  states  the  invariant  condition  that  all  objects  within  class 
X  must  be  non-cyclic  over  the  self-referencing  object-valued  attribute  x-obj  while  axioms  (b)  and 
(c)  recursively  define  the  operation  over  all  objects  within  the  aggregate. 

6.5.2  Qualified  Aggregates.  Because  aggregation  is  a  form  of  association,  qualifiers  may 
be  specified  between  aggregates  and  their  components.  Aggregate  qualifiers  are  a  special  case  of 
association  qualifiers  and  are  defined  as  special  attributes  used  to  reduce  the  multiplicity  of  an 
aggregation.  Just  as  in  associations,  a  qualifier  is  used  to  distinguish  among  a  set,  or  class,  of 
objects.  For  instance,  a  bank  may  have  many  customers;  however,  if  the  aggregation  is  modeled 
with  a  customer  number  qualifier  as  shown  in  Figure  6.32,  the  aggregation  becomes  one-to-one 
since  each  customer  has  a  unique  customer  number. 


Figure  6.32  Aggregate  Qualifier 
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In  the  theory-based  object  model,  qualifiers  are  modeled  as  an  attribute  of  the  qualified  class 
with  a  qualified  image  operation  defined  in  its  class  set.  This  image  operation  is  similar  to  those 
for  qualified  associations  that  select  components  from  a  class  set  based  on  the  qualifier.  Again,  the 
multiplicity  axioms  of  Figure  6.24  are  used  to  restrict  the  qualified  aggregate  using  the  qualified 
image  operation. 

An  example  of  a  qualified  bank  -  customer  aggregation  is  shown  in  Figures  6.33  and  6.34.  The 
CUSTOMER  class  type  definition  includes  the  qualifier  cust-no  as  a  normal  attribute.  Therefore,  to 
create  a  new  customer,  a  name,  address,  and  customer  number  must  be  provided.  The  Oust- Class 
class  set  is  modified  by  adding  an  image  operation  with  the  cust-no  qualifier.  The  update-customer 
class  event  is  used  in  conjunction  with  the  image  operation  to  perform  the  update- customer  event 
on  a  single  customer  as  designated  via  the  cust-no  (e.g.,  update-customer(image(customer-class, 
cust-no),  new-name,  neui-address)).  Thus,  as  stated  by  the  axiom  size{image{cc,n))  =  1,  the 
aggregate  multiplicity  is  changed  from  one-to-many  to  one-to-one. 

6.5.3  Specification  of  Behavior.  Once  an  aggregate  is  created  via  a  colimit  operation, 
further  specification  is  required  to  make  the  aggregate  behave  in  an  integrated  manner.  First,  new 
aggregate  level  functions  are  defined  to  enable  the  aggregate  to  respond  to  external  events.  Then, 
constraints  between  aggregate  components  are  specified  to  ensure  that  the  aggregates  do  not  behave 
in  an  unsuitable  or  unexpected  manner,  and  finally,  local  event  communication  paths  are  defined. 
The  definition  of  new  functions  and  constraints  is  discussed  in  this  section  while  communication 
between  objects  is  discussed  in  Section  6.6. 

6. 5. 3.1  Specification  of  Functionality.  In  an  aggregate,  components  work  together 
to  provide  the  desired  functionality.  This  desire  to  define  functionality  across  components  leads 
naturally  to  the  use  of  the  functional  model.  The  functional  model  is  used  to  specify  the  results  of 
a  computation  without  defining  where  or  how  they  are  computed  and  is  used  to  define  actions  gen- 
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class  Customer  is 
import  Name,  Address,  Cust-No 
class  sort  Customer 
operations 

attr-equal  :  Customer,  Customer  Boolean 
attributes 

name  :  Customer  — ♦  Name 
address  ;  Customer  — ♦  Address 
cust-no  :  Customer  — »  Cust-No 
methods 

create-customer  :  Name,  Address,  Cust-No  — >  Customer 
update  :  Customer,  Name,  Address,  Cust-No  — >  Customer 
events 

new-customer  ;  Name,  Address,  Cust-No  — >  Customer 
update-customer  :  Customer,  Name,  Address  — ►  Customer 
axioms 

%  operation  definition 

V  (c,cl:  Customer)  attr-equal(c,cl)  name(c)  =  name(cl) 

A  address(c)  =  address(cl)  A  cust-no(c)  =  cust-no(cl); 

%  create  method  definition 

V  (n:  Name,  a:  Address,  cn:  Cust-No) 
name(create-customer(n,a,cn))  =  n  A  address{create-customer(n,a,cn)) 
A  cust-no(create-customer(n,a,cn))  =  cn; 

%  update  method  definition 

V  (c:  Customer,  n:  Name,  a:  Address,  cn:  Cust-No) 
name(update(c,n,a,cn))  =  n  A  address(update(c,n,a,cn))  =  a 
A  cust-no(update(c,n,a,cn))  =  cn; 

%  new  event  definition 

V  (n;  Name,  a:  Address,  cn:  Cust-No) 
attr-equal(new-customer(n,a,cn),  create-customer(n,a,cn)); 

%  update- customer  event  definition 

V  (c:  Customer,  n:  Name,  a:  Address,  cn:  Cust-No) 
attr-equal(update-customer(c,n,a,cn),  update(c,n,a,cn)) 

end-class 


Figure  6.33  Qualified  Customer  Class 
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class  Cust-Class  is 
contained-class  GUST 
class  sort  Cust-Class 
operations 

attr-equal;  Cust-Class,  Cust-Class  Boolean 
methods 

image  :  Cust-Class,  Cust-No  — >  Cust-Class 
events 

new-cust-class  :  — ►  Acct-Class 

update-customer  :  Cust-Cl2iss,  Name,  Address  Cust-Class 
axioms  V  (c;  Cust,  n:  Name,  a:  address,  cc;  Cust-Class) 

V  (cc;  Cust-Class,  n:  Name)  size(image(cc,n))  =  1; 

new-cust-class  =  empty-set; 

V  (c;  Cust,  cc:  Cust-Class,  n:  Name,  a:  Address) 

c  €  cc  update-customer(c,n,a)  €  update-customer(cc,n,a); 

...  definition  of  image  operations  ... 
end-class 

Figure  6.34  Qualified  Customer  Class  Set 


erated  by  the  dynamic  model  (83:123).  Processes  defined  in  the  functional  model  are  implemented 
using  events  and  attributes  defined  in  the  aggregate  components. 

An  example  of  defining  the  functional  behavior  of  an  aggregate  using  the  functional  model 
is  shown  in  Figure  6.35  with  the  full  specification  shown  in  Figure  6.36.  The  Bank  aggregate 
actually  defines  three  new  events  {start- account,  make-deposit,  and  make-withdrawat)  and  a  derived 
attribute  balance.  The  functional  model  defines  the  method  implementing  the  start-account  event, 
add-account  as  shown  in  Figure  6.35.  The  make-deposit  and  make-withdrawal  events  map  directly 
to  component  events  and  do  not  require  a  functional  decomposition. 

Figure  6.35  shows  the  functional  model  for  the  add-account  action.  The  left-hand  side  is 
the  top-level  diagram  while  the  right-hand  side  shows  the  decomposition  of  add-account.  The 
add-account  process  adds  an  account  for  an  established  customer.  The  following  axiom  defines  add- 
account  in  terms  of  its  subprocesses  and  data  flows  and  is  translated  directly  from  the  functional 
model  using  the  restricted  functional  model  semantics  described  in  Section  5.5. 
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Figure  6.35  Bank  Aggregate  Functional  Model 


add-account(b,  customer,  acct-no)  =  61 

A  acct  =  new-acct(date)  %%  assume  date  is  built  in 
A  acct-obj(bl)  =  update-accts(acct-obj{b),acct) 

A  cust-acct  —  new-cust-acct{customer,  acct,  acct-no) 

A  cu3t-acct{bl)  =  update-cust-acct{cust-acct{b), cust-acct)'. 

The  add-account  method  has  three  parameters,  the  bank  object  (6)  plus  an  account  number  and  an 
existing  customer  object  as  defined  in  the  functional  model,  and  returns  the  modified  bank  object 
(61).  The  add-account  method  is  defined  by  its  subprocesses.  First,  a  new  account  is  created  by 
invoking  the  new-account  event  which  is  then  passed  to  the  update-accts  process  which  stores  the 
new  account  in  the  account  class.  Then,  the  new  account  is  passed  as  a  parameter  to  the  new- 
cust-acct  event  which  returns  a  cust-acct  link  which  relates  the  customer,  the  account  number,  and 
the  new  account.  Finally,  the  new  cust-acct  link  is  passed  to  the  update-cust-acct  process  which 
stores  it  in  the  cust-acct  association.  The  subprocesses  in  Figure  6.35  are  not  defined  here.  The 
new-account  and  new-cust-acct  processes  are  the  events  defined  in  the  account  class  and  cust-acct 
association  respectively  and  are  already  available  via  the  aggregate.  The  update-accts  and  update- 
cust-acct  processes  either  already  exist  as  part  of  the  account  class  and  cust-acct  association  or 
may  be  defined  in  this  specification. 
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class  Bank  is 

import  BANK-AGGREGATE 
class  sort  Bank 
operations 

balance  :  Bank,  Acct-No  Amnt 
attr-equal  :  Bank,  Bank  — t  Boolean 
attributes 

acct-obj  :  Bank  — »  Acct-Class 
cust-obj  :  Bank  — »  Gust-Class 
cust-acct-assoc  :  Bank  — *  Cust-Acct 
methods 

create-bank  :  — »  Bank 

add-account  ;  Bank,  Customer,  Acct-No  —*  Bank 
update-accts  :  Acct-Class,  Acct  — »  Acct-Class 
update-cust-acct  :  Cust-Acct,  Cust-Acct-Link  — »  Cust-Acct 
events 

new-bank  :  — >  Bank 

start-account  ;  Bank,  Customer,  Acct-No  — +  Bank 
make-deposit,  make- withdrawal  ;  Bank,  Acct-No,  Amnt  — ►  Bank 
SLxioms  %  invariants 

V  (a;  Acct-Class,  c:  Cust-Class)  size(a)  >  0  A  size(c)  >  0; 

V  (c;  Cust-Acct-Class,  b;  Bank,  a;  Acct-No)  size(c)  >  0  A  balance(b,a)  >  0; 

%  definition  of  operations 

V  (b,bl:  Bank)  attr-equal(b,bl)  acct-obj(b)  =  acct-obj(bl) 

A  cust-obj(b)  =  cust-obj(bl)  A  cust-acct-assoc(b)  =  cust-acct-assoc(bl); 

V  (b:  Bank,  a;  Address,  an;  Acct-No,  c:  Customer)  size(image(acct-obj{b),c,an))  =  1 
^  singleton(a)  =  image(acct-obj(b),c,an)  A  balance(b,an)  =  bal(a); 

%  definition  of  methods 
acct-obj(create-bank())  =  create-acct-class(); 
cust-obj  (create-bank 0)  =  create-cust-class(); 
cust-acct-assoc(create-bank())  =  create-cust-acct(); 

V  (b,  bl;  Bank,  an;  Acct-No,  c;  Customer) 
add-account(b,  c,  an)  =  bl 

A  acct  =  new- acct  (date)  %%  date  built  in 
A  acct-obj(bl)  =  update-accts(acct-obj(b),  acct) 

A  cust-acct  =  new-cust-acct(cust,  acct,  acct-no) 

A  cust-acct(bl)  =  update-cust-acct(cust-acct(b),  cust-acct); 

%  definition  of  events 
attr-equal(new-bank() ,  create-bank()) ; 

V  (b;Bank,  an;Acct-No,  c;Customer)  attr-equal(start-account(b,c,an),add-account(b,c,an)) 

V  (b;  Bank,  an;  Acct-No,  c;  Customer,  am;  Amount)  size(image(acct-obj(b),c,an))  =  1 
=>  attr-equal(image(cust-acct-assoc(make-deposit(b,an,am),c,an)), 

deposit  (image(cust-acct-assoc(b)  ,c,an)  ,am) ) ; 

V  (b:  Bank,  an;  Acct-No,  c;  Customer,  am;  Amount) 
size(image(acct-obj(b),c,an))  =  1  A  balance(b,an)  >  x 

=>  attr-equal(image(cust-acct-assoc(make-withdrawal(b,an,am))), 
withdrawal(image(cust-acct-assoc(b),c,an),am)) 
end-class 


Figure  6.36  Full  Aggregate  Specification 
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Both  the  make- deposit  and  make-withdrawal  events  mirror  events  defined  in  the  ACCT  class 


and  thus  invoke  those  events  directly.  However,  because  the  bank  aggregate  has  the  requirement 
to  ensure  an  account  does  not  overdraw  its  available  cash,  a  precondition  is  placed  on  the  make- 
withdrawal  event. 


size(image{acct-obj{b),c,an))  =  1  A  balance{b,  an)  >  x 

=>  attr-equal(image{cu3t-acct-a3soc(make-withdrawal{b,an,  am))), 
withdrawal(image{cust-acct-assoc{b),c,  an),  am)) 

Because  the  ACCT  class  allowed  an  account  to  be  overdrawn  exactly  once,  a  precondition  overriding 
the  ACCT  withdrawal  precondition  was  added.  This  is  a  case  of  restricting  the  behavior  of  the 
aggregate. 

The  derived  attribute  balance  is  different  from  the  attributes  defined  in  Section  6.2  in  that 
it  takes  additional  parameters.  The  additional  parameter  is  due  to  the  fact  that  balance  is  not  an 
attribute  of  a  bank,  but  of  an  account.  The  parameter  acct-no  is  required  to  uniquely  identify  a 
specific  account.  The  axiom  below  defines  the  balance  attribute. 

size{image{acct-obj(b),c,an))  =  1 

singleton{a)  =  image{acct-obj{b),c,an)  A  balance{b,an)  =  bal{a) 

Because  the  image  function  returns  a  set  of  accounts,  a  few  axiomatic  gymnastics  are  required 
to  define  the  operation.  While  this  additional  complexity  seems  unnecessary,  use  of  sets  with 
object-valued  attributes  provides  the  most  flexible  approach  to  building  domain  models  and  can  be 
simplified  in  the  functional  specification  generated  by  Specification  Generation/Refinement  System 
as  defined  in  Chapter  II. 

6. 5. 3. 2  Specification  of  Constraints  Between  Components.  In  an  aggregate,  compo¬ 
nent  behavior  must  often  be  constrained  if  the  aggregate  is  to  act  in  an  integrated  fashion.  For 
instance,  in  an  automobile  there  is  an  engine,  transmission,  and  four  wheels;  however,  they  do  not 
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act  independently.  When  the  engine  is  running  and  the  transmission  is  engaged,  there  is  a  exact 
relationship  that  exists  between  the  engine  speed,  transmission  state,  and  the  wheel  rotation  speed. 
This  relationship  is  a  constraint  between  the  automobile  components.  Generally,  these  relationships 
are  expressed  by  axioms  defined  over  component  attributes.  Because  the  aggregate  is  the  colimit  of 
its  components,  the  aggregate  may  access  components  directly  and  define  axioms  relating  various 
component  attributes. 


Figure  6.37  Automobile  Aggregate  Functional  Model 


A  simplified  automobile  object  model  is  shown  in  Figure  6.37.  The  object  model  contains 
one  engine  with  an  RPMs  attribute,  one  transmission  with  a  Conversion-Factor  attribute,  and  four 
wheels,  each  with  an  RPMs  attribute.  Two  relationships  exist  between  these  objects.  Drives,  that 
relates  the  transmission  to  exactly  two  wheels,  and  Connected  that  relates  two  wheels  (probably 
by  an  axle).  Obviously,  there  are  a  number  of  constraints  implicit  in  the  object  model  that  must 
be  made  explicit  in  the  aggregate.  First,  as  discussed  above,  the  RPMs  of  the  engine,  Conversion- 
Factor  of  the  transmission,  and  RPMs  of  the  wheels  are  all  related.  Also,  the  wheels  driven  by  the 
transmission  must  be  “connected” ,  and  all  “connected”  wheels  should  have  the  same  RPMs.  These 
constraints  can  be  specified  in  the  aggregate  specification  shown  in  Figure  6.38.  The  axiom 

V(e  :  Engine,  t :  Transmission,  d  :  Drives) 

e  €  engine-obj{a)  At  £  tranamission-obj{a)  A  d  €  drives-assoc{a) 
rpm{wheel-obj{d))  =  rpm{e)  *  conver sion- factor [t) 
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class  Automobile  is 

import  AUTOMOBILE-AGGREGATE 

class  sort  Automobile 

operations 

attr-equal  :  Automobile,  Automobile  — >  Boolean 
attributes 

engine-obj  :  Automobile  — >  Engine-Class 
transmission-obj  :  Automobile  Transmission-Class 
wheels-obj  :  Automobile  — >  Wheels- Class 
drives-assoc  :  Automobile  — »  Drives 
connected-assoc  :  Automobile  — >  Connected 
methods 

create-automobile  :  — >  Automobile 
events 

new-automobile  :  — >  Automobile 
eixioms 
%  invariants 

V  (ec:  engine-class)  size(ec)  =  1; 

V  (tc:  transmission-class)  size(tc)  =  1; 

V  (wc:  wheels-obj)  size(wc)  =  4; 

V  (d;  drives-assoc)  size(d)  =  2; 

V  (c:  connected-assoc)  size(c)  =  2; 

%  constraints 

V  (e:  Engine,  t:  Transmission,  d:  Drives) 

e  €  engine-obj(a)  A  t  €  transmission-obj  (a)  A  d  €  drives-assoc(a) 

^  rpm(wheel-obj(d))  =  rpm(e)  *  conversion-factor(t); 

V  (c:  Connected)  c  €  connected-assoc(a))  =>  rpm(wheell(c))  =  rpm(wheel2(c)); 

%  definition  of  attr-equal 

V  (a,al:  Automobile) 

attr-equal(a,al)  =?>•  engine-obj(a)  =  engine-obj  (al) 

A  transmission-obj  (a)  =  transmission-obj(al) 

A  wheels-obj  (a)  =  wheels-obj  (al) 

A  drives-assoc(a)  =  drives-assoc(al) 

A  connected-assoc(a)  =  connected-assoc(al); 

%  definition  of  create-automobile 
t  =  new-transmission() 

A  wl  =  new-wheel()  A  w2  =  new-wheel()  A  w3  =  new-wheel()  A  w4  =  new-wheel() 

A  transmission-obj(create-automobile())  =  insert(t,  new-transmission-class()) 

A  drives-assoc(create-automobile())  = 
insert  (new-drives-link(t  ,w2)  ,insert(new-drives-link(t  ,wl)  ,new-drives() ) ) 

A  connected-assoc(create-automobile())  = 

insert(new-connected-link(wl,w2),insert(new-connected-link(w3,w4),new-connected())) 
A  engine-obj(create-automobile())  =  insert(new-engine(),  new-engine-class()); 

%  definition  of  new-automobile 

attr-equal(new-automobile(),  create-automobile()) 
end-class 


Figure  6.38  Automobile  Aggregate  Specification 
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defines  the  relationship  between  the  RPMs  of  the  wheels  driven  by  the  transmission,  the  transmis¬ 
sion  conversion-factor  and  the  engine  RPMs.  While  written  in  set  notation,  the  invariants  state 
that  the  size  of  the  engine  and  transmission  class  sets  is  only  one;  therefore,  the  axiom  uniquely 
identifies  the  engine,  transmission,  and  each  wheel  driven  by  the  transmission.  The  axiom 
V(c  :  Connected)c  £  connected-assoc{a))  =>  rp7n{wheell{c))  =  rpm{wheel2{c))\ 

ensures  that  the  two  wheels  connected  in  a  “connected”  link  have  the  same  RPMs  values.  The  final 
constraint,  that  the  two  wheels  driven  by  the  transmission  be  connected,  is  specified  implicitly  in 
the  specification  of  the  create-automohile  method.  Because  the  create-automobile  method  creates 
its  components  when  invoked,  the  relationships  of  the  wheels  can  be  controlled  directly.  After  the 
wheel  objects  (ml,  m2,  m3,  and  m4)  are  created,  links  are  created  for,  and  inserted  into,  the  drives 
and  connected  associations  as  defined  below. 

A  drives-as30c{create-automobile())  = 

insert{new-drives-link(t,  m2),  insert{new-drives-link{t,  ml),  new-drivesi))) 

A  connected-assoc(create-autom,obile{))  = 

insert{new-connected-link{wl,  m2),  insert{new-connected-link{w3,  m4),  new-connected{))) 

Because  wheels  ml  and  m2  are  associated  with  the  transmission  via  the  drives  association  in  the 
first  line,  they  are  also  a.ssociated  together  via  the  connected  association  in  the  second  line.  Thus, 
the  constraint  is  satisfied  whenever  an  automobile  aggregate  object  is  created. 

6. 6  Communication 

At  this  point  the  theory-based  object  model  is  sufficient  for  describing  classes,  their  relation¬ 
ships,  and  their  composition  into  aggregate  classes;  however,  object  communication  has  not  yet 
been  addressed.  For  example,  suppose  the  banking  system  described  earlier  has  an  ARCHIVE 
object  which  logs  each  transaction  as  it  occurs.  Obviously,  the  ARCHIVE  object  must  be  told 
when  a  transaction  takes  place.  This  communication  is  accomplished  in  one  of  three  ways.  The 
simplest  method  is  to  force  the  BANK  aggregate  to  be  responsible  for  directly  invoking  events  in 
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each  object  to  accomplish  the  archival  function  and  passing  the  appropriate  information  to  each 
object.  While  simple  in  this  example,  as  aggregate  complexity  and  object  interaction  increases,  an 
enormous  burden  is  placed  on  the  aggregate. 

A  second  solution  is  to  make  each  object  responsible  for  handling  its  own  communications. 
Each  object  directly  communicates  with  other  objects  by  maintaining  internal  object-valued  at¬ 
tributes  and  invoking  their  events  directly.  Unfortunately,  if  each  object  is  required  to  know  each 
object  with  which  it  may  communicate,  reusability  is  lost  since  those  objects  may  not  exist  in  a 
different  system. 

The  third,  and  preferred,  method  is  a  combination  of  the  above  techniques.  In  this  method, 
each  object  is  aware  of  only  a  certain  set  of  events  that  it  generates  or  receives.  Prom  an  object’s 
perspective,  these  events  are  generated  and  broadcast  to  the  entire  system  and  received  from  the 
system.  In  this  technique,  each  event  is  defined  in  a  separate  event  theory  as  shown  in  Figure  6.39. 

event  Archive-Withdrawal  is 
class  sort  Archive 
sorts  Acct,  Amnt 
events 

archive-withdrawal  :  Archive,  Acct,  Amnt  — +  Archive 
end-class 

Figure  6.39  Event  Theory 

An  event  theory  consists  of  a  class  sort,  parameter  sorts,  and  an  event  signature  that  are 
mapped  via  signature  morphisms  to  sorts  and  events  in  the  generating  and  receiving  classes.  The 
event  theory  class  sort  represents  the  class  sort  of  any  class  whose  objects  can  receive  the  associated 
event.  Because  events  are  actually  sent  to  individual  objects  represented  by  object-valued  attributes 
as  defined  in  Section  6.2.9,  an  event  may  only  be  sent  to  one  object  in  the  event  theory  class  sort. 
Therefore,  if  the  event  theory  class  sort  is  mapped  to  the  class  sort  of  class  X  then  communication 
occurs  with  a  single  object  from  class  X.  However,  if  the  event  theory  class  sort  is  mapped  to  the 
class  sort  of  the  class  set  of  type  X  (i.e.,  X-CLASS),  then  communication  may  occur  with  a  set  of 
objects  of  class  X.  The  other  sorts  defined  in  an  event  theory  class  are  the  sorts  of  other  parameters 
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of  the  event.  The  final  part  of  an  event  theory  is  the  event  signature  itself.  This  signature  is  mapped 
to  an  event  in  the  receiving  classes  with  compatible  parameters  as  defined  in  the  event  theory.  Once 
the  event  and  sorts  are  mapped  to  the  required  class  specifications  under  signature  morphisms,  the 
colimit  of  the  classes,  the  event  theory,  and  the  morphisms  unify  the  event  and  sorts  such  that  any 
invocation  of  the  event  in  the  generating  class  is  an  invocation  of  the  actual  event  in  the  receiving 
class. 

Figure  6.40  shows  how  an  event  theory  would  be  incorporated  into  the  original  ACCT  class. 
The  ARCHIVE-  WITHDRAWAL  event  theory  specification  is  imported  into  the  ACCT  class  and  an 
object-valued  attribute,  archive-obj,  is  added  to  reference  the  archival  object.  The  axioms  defining 
the  effect  of  the  withdrawal  event  are  modified  to  reflect  the  communication  with  the  ARCHIVE 
object  as  shown  below. 

V(a  :  Acct,  x  :  Amnt)acct-state{a)  =  ok  A  bal{a)  >x^  acct-state{withdrawal{a,x))  =  ok 
A  archive-obj{withdTawal{a,x))  =  archive-withdrawal{archive-obj{a),a,x) 

A  attr-equal{withdrawal(a,x),  debit(a,  a;)); 

V(a  :  Acct,  x  \  Amnt)acct-state{a)  =  ok  A  bal{a)  <  x  acct-state{withdra'wal{a,x))  =  overdrawn 
A  archive-obj {withdrawal(a,x))  =  archive-withdrawal{archive-obj{a),a,x) 

A  attr-equal{withdrawal{a,x),debit{a,x))\ 

Basically,  the  axioms  state  that  when  a  withdrawal  event  is  received,  the  value  of  the  archive-obj  is 
modified  by  the  archive- withdrawal  event  defined  in  the  event  theory  specification.  Thus  the  ACCT 
object  knows  it  communicates  with  some  other  object  or  objects;  however,  it  does  not  know  who 
they  are.  With  whom  an  object  communicates  (or,  for  that  matter,  if  the  object  communicates 
at  all)  is  determined  at  the  aggregate-level  where  the  actual  connections  between  communicating 
components  are  made.  In  this  example,  for  instance,  there  could  be  zero,  one,  or  many  archival 
objects. 

Figure  6.41  shows  a  modified  BANK  aggregate  that  includes  the  ARCHIVE-WITHDRAWAL 
event  theory  and  an  ARCHIVE-CLASS  specification.  The  colimit  operation  includes  morphisms 
from  ARCHIVE-WITHDRAWAL  to  ACCT-CLASS  and  ARCHIVE-CLASS  ih&t  unify  the  sorts 
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class  Acct  is 

import  Amnt,  Date,  Archive-Withdrawal 
class  sort  Acct 
sorts  Acct-State 
operations 

attr-equal  :  Acct,  Acct  — ►  Boolean 
attributes 

date  :  Acct  — »  Date 
bal  :  Acct  Amnt 
archive-obj  :  Acct  -+  Archive 
state-attributes 

acct-state  :  Acct  Acct-State 
methods 

create-acct  :  Date,  Archive  -+  Acct 
credit,  debit  :  Acct,  Amnt  — +  Acct 
states 

ok,  overdrawn  :  — +  Acct-State 
events 

new-acct  :  Date,  Archive  — >  Acct 
deposit,  withdrawal  ;  Acct,  Amnt  Acct 
axioms 

ok  ^  overdrawn; 

V  (a:  Acct)  acct-state(a)  =  ok  =>  bal(a)  >  0; 

V  (a:  Acct)  acct-state(a)  =  overdrawn  =>  bal(a)  <  0; 

%  operation  definitions 

V  (a,al:  Acct)  attr-equal(a,al) 

date(a)=date(al)  A  bal(a)=bal(al)  A  archive-obj(a)=archive-obj(al); 

%  method  definitions 

V  (d:  Date,  o:  Archive)  date(create-acct(d,o))  =  d  A  bal(create-acct(d,o))  =  0 
A  aichive-obj(create-acct(d,o))  =  o; 

V  (a:  Acct,  x;  Amnt)  bal(credit(a,x))  =  bal(a)  -I-  x  A  date(credit(a,x))  =  date(a) 

A  rate(credit(a,x))  =  rate(a)  A  int-date(credit(a,x))  =  int-date(a) 

A  check-cost  (credit  (a,x))  =  check-cost(a); 

%  event  definitions 

V  (d:  Date)  acct-state(new-acct(d,o))  =  ok  A  attr-equal(new-acct(d,o),  create-acct(d,o)); 

V  (a;  Acct,  x:  Amnt)  acct-state(a)  =  ok  =>  acct-state(deposit(a,x))  =  ok 
A  attr-equal(deposit(a,x),  credit(a,x)); 

V  (a:  Acct,  x:  Amnt)  acct-state(a)  =  overdrawn  A  bal(a)  -|-  x  >  0  =>  acct-state(deposit(a,x))  =  ok 
A  attr-equal(deposit(a,x),  credit(a,x)); 

V  (a:  Acct,  x:  Amnt)  acct-state(a)  =  overdrawn  A  bal(a)  -I-  x  <  0 

=>  acct-state(deposit(a,x))  =  overdrawn  A  attr-equal(deposit(a,x),  credit(a,x)); 

V  (a;  Acct,  x:  Amnt)  acct-state(a)  =  ok  A  bal(a)  >  x  acct-state(withdrawal(a,x))  =  ok 
A  attr-equal(withdrawal(a,x),  debit(a,x)) 

A  archive-obj (withdrawal(a,x))  =  archive- withdrawal(archive-obj (a) ,a,x); 

V  (a:  Acct,  x:  Amnt)  acct-state(a)  =  ok  A  bal(a)  <  x  =>■  acct-state(withdrawal(a,x))  =  overdrawn 
A  attr-equal{withdrawal(a,x),  debit(a,x)) 

A  axchive-obj(withdrawal(a,x))  =  archive-withdrawal(archive-obj(a),a,x); 

V  (a:  Acct,  x:  Amnt)  acct-state(a)  =  overdrawn  acct-state(withdrawal(a,x))  =  overdrawn 
A  attr-equal(withdrawal(a,x),  a) 

end-class 


Figure  6.40  Account  Class  with  Communications 
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and  event  signature  in  ACCT-CLASS  with  the  sorts  and  event  signature  of  ARCHIVE-CLASS. 
This  unification  creates  the  communication  path  between  account  objects  and  archive  objects. 
When  an  account  object  invokes  the  archive-withdrawal  event,  it  is  actually  invoking  the  archive- 
withdrawal  event  of  the  archive  class  object.  The  simplified  BANK  composition  diagram  is  shown 
in  Figure  6.42.  The  INTEGER  and  SET  specifications  and  the  associated  morphisms  shown  in 
Figure  6.28  are  left  out  for  simplicity,  but  still  apply. 


aggregate  Bank- Aggregate  is 

nodes  INTEGER,  SET-1:  SET,  SET-2:  SET,  ACCT-CLASS, 

CUST-CLASS,  CUST-ACCT,  ARCHIVE- WITHDRAWAL,  ARCHIVE-CLASS 
arcs  SET-1  ACCT-CLASS  :  {E  Acct,  SET  Acct-Class}, 

SET-1  CUST-ACCT  :  {E  Account,  SET  Acct-Class}, 

SET-2  — »  CUST-CLASS  :  {E  -+  Customer,  SET  — >  Cust-Class}, 

SET-2  CUST-ACCT  :  {E  -+  Customer,  SET  — >  Customers}, 

SET-3  —  CUST-ACCT  :  {E  ^  CA-Link,  SET  Cust-Acct}, 

INTEGER  SET-1  :  {}, 

INTEGER  SET-2  :  {}, 

INTEGER  -  SET-3  :  {}, 

INTEGER  ARCHIVE-CLASS  :  {}, 

ARCHIVE- WITHDRAWAL  ACCT-CLASS:  {}, 

ARCHIVE- WITHDRAWAL  -+  ARCHIVE-CLASS:  {} 
end-aggregate 


Figure  6.41  Communicating  Bank  Aggregate  Class 


Archive-Withdrawal 


Cust-Class 


Communicating  with  objects  from  multiple  classes  requires  the  addition  of  another  level  of 


specification  which  “broadcasts”  the  communication  event  to  all  interested  object  classes.  The 
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class  sort  of  a  broadcast  theory  is  called  a  broadcast  sort  and  represents  the  object  with  which  the 
sending  object  communicates.  The  broadcast  theory  then  defines  an  object-valued  attribute  for 
each  receiving  class.  Figure  6.43  shows  an  example  of  the  ARCHIVE-WITHDRAWAL-MULT  event 
theory  modified  to  communicate  with  two  classes.  In  this  case,  the  ARCHIVE-WITHDRAWAL 
theory  is  used  to  unify  the  ARCHIVE-WITHDRAWAL-MULT •'Nii'h  the  ACCOUNT  class  as  well 
as  the  other  two  classes.  An  example  of  the  required  colimit  specification  is  shown  in  Figure  6.44 
while  the  diagram  of  the  specification  (showing  only  the  morphisms  between  event  and  broadcast 
theories)  is  shown  in  Figure  6.45. 


event  Archive-Withdrawal-Mult  is 
class  sort  Archive 
sorts  Amnt,  Acct,  X,  Y 
attribute 

x-obj  :  Archive  ^  X 
y-obj  :  Archive  — ♦  Y 
events 

archive-withdrawal  :  Archive  ,  Acct,  Amnt  Archive 
archive-withdrawal  :  X,  Acct,  Amnt  — ►  X 
axchive-withdrawal  :  Y,  Acct,  Amnt  — >  Y 
axioms 

V  (a;  Archive,  ac:  Acct,  am:  Amnt) 

x-obj  (archive- withdrawal(a,ac,am))  =  archive- withdrawal(x-obj  (a)  ,ac,am) 

A  y-obj  (archive- withdrawal(a,ac,am))  =  archive- withdrawal(y-obj  (a), ac, am) 
end-class 


Figure  6.43  Broadcast  Theory 


Multiple  receiver  classes  add  a  layer  of  specification;  however,  multiple  sending  classes  is 
handled  very  simply.  The  only  additional  construct  required  is  a  morphism  from  each  sending  class 
to  the  event  theory  mapping  the  appropriate  object-valued  attribute  in  the  sending  class  to  the  class 
sort  of  the  event  theory  and  the  event  signature  in  the  sending  class  to  the  event  signature  in  the 
event  theory.  A  diagram  showing  the  effect  of  a  second  class  sending  the  same  archive-withdrawal 
event  is  shown  in  Figure  6.46. 

A  question  requiring  further  research  is  how  to  specify  exactly  which  objects  in  communicating 
classes  actually  communicate.  In  the  banking  example  using  a  single  archival  object,  the  problem 
is  straightforward.  Send  the  events  to  the  only  instance  of  the  class.  Determining  which  classes 
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aggregate  Bank- AGGREGATE  is 

nodes  INTEGER,  SET-1;  SET,  SET-2:  SET,  ACCT-CLASS,  GUST-CLASS, 

ARCHIVE- WITHDRAWAL-1:  ARCHIVE- WITHDRAWAL,  CUST-ACCT, 
ARCHIVE- WITHDRAWAL-2:  ARCHIVE- WITHDRAWAL,  ARCHIVE-CLASS, 
ARCHIVE- WITHDRAWAL-3:  ARCHIVE- WITHDRAWAL,  PRINTER-CLASS 
arcs  SET-1  ACCT-CLASS  ;  {E  -4  Acct,  SET  Acct-Class}, 

SET-1  -*  CUST-ACCT  :  {E  ^  Account,  SET  -4  Acct-Class}, 

SET-2  — >  CUST-CLASS  :  {E  -4  Customer,  SET  — »  Cust-Class}, 

SET-2  — »  CUST-ACCT  :  {E  — ►  Customer,  SET  — »  Customers}, 

SET-3  ^  CUST-ACCT  ;  {E  CA-Link,  SET  Cust-Acct}, 

INTEGER  -»  SET-1  :  {}, 

INTEGER  SET-2  :  {}, 

INTEGER  SET-3  :  {}, 

INTEGER  —  ARCHIVE-CLASS  ;  {}, 

ARCHIVE- WITHDRAWAL-1  -4  ACCT-CLASS:  {}, 

ARCHIVE- WITHDRAWAL-1  ARCHIVE-WITHDRAWAL-MULT:  {} 
ARCHIVE-WITHDRAWAL-2  -4  ARCHIVE-CLASS:  {}, 

ARCHIVE- WITHDRAWAL-2  -4  ARCHIVE- WITHDRAWAL-MULT:  {Archive  -4  X}, 
ARCHIVE- WITHDRAWAL-3  ^  PRINTER-CLASS:  {}, 

ARCHIVE- WITHDRAWAL-3  ^  ARCHIVE- WITHDRAWAL-MULT:  (Archive  Y} 

end-aggregate 


Figure  6.44  Unification  of  Multiple  Broadcast  Classes 


Archive-Withdrawal-Mult 


Figure  6.45  Aggregate  Using  a  Broadcast  Theory 
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Archive-Withdrawal-Mult 


Figure  6.46  Aggregate  Using  a  Broadcast  Theory  With  Multiple  Generators 

communicate  is  much  simpler  and  is  defined  in  the  dynamic  model  based  on  event  name  equivalence. 
If  there  is  only  one  instance  of  a  receiving  class,  then  this  model  completely  describes  which  objects 
communicate;  all  instances  of  the  account  class  communicate  with  the  archive  object  and  the  printer 
object.  However,  if  certain  accounts  must  send  their  archive  events  to  certain  archive  or  printer 
objects,  then  the  model  breaks  down.  An  extension  to  the  OMT  model  is  required;  however,  that 
extension  is  not  defined  in  this  research.  Because  the  theory-based  object  model  is  used  for  domain 
modeling,  describing  what  classes  may  communicate  is  acceptable.  Determining  exactly  which 
objects  communicate  is  dealt  with  in  the  System  Generation/ Refinement  Subsystem  as  defined  in 
Chapter  II. 

6.6.1  Communication  Between  Aggregate  and  Components.  Communication  between 
components  is  handled  at  the  aggregate  level  as  described  above.  However,  when  the  communication 
is  between  the  aggregate  and  one  of  its  components,  the  unification  of  object-valued  attributes  and 
class  sorts  via  event  theories  does  not  work.  Consider  the  example  where  a  component  sends  an 
event  that  is  received  by  its  aggregate.  An  event  theory  can  be  created;  however,  because  the  class 
sort  of  the  aggregate  is  not  created  until  after  the  colimit  is  computed,  the  object-valued  attribute 
from  the  event  theory  and  the  aggregate  class  sort  cannot  be  unified  in  the  colimit  operation.  There 
are  two  solutions  to  this  problem. 
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The  first,  and  simplest  solution  is  to  perform  the  unification  at  the  next  higher  level  aggre¬ 
gate  or  domain-level  specification.  This  is  the  solution  implemented  in  the  translation  defined  in 
Chapter  VII.  Since  each  class  is  a  component  of  an  overall  domain  model  class,  the  unification  is 
performed  at  that  level. 

The  second  solution  requires  the  use  of  a  sort  axiom  that  equivalences  two  or  more  sorts  as 
shown  below: 

sort-axiom  sortl  =  sort2 

Using  the  automobile  example  discussed  above,  assume  the  Engine  generates  an  engine-warning 
event  that  is  received  by  the  Automobile  aggregate.  The  event  theory  for  such  an  event  is  shown 
in  Figure  6.47.  This  event  theory  is  included  into  the  Engine  class  type  definition  and,  by  the 
colimit  operation,  the  Automobile  aggregate.  To  enable  the  Automobile  aggregate  to  receive  the 
engine- warning  event,  it  uses  a  sort-axiom  to  equivalence  the  Automobile  sort  of  the  aggregate  with 
the  Controller  sort  from  the  event  theory  as  shown  in  Figure  6.48.  Use  of  the  sort  axiom  unifies 
the  Automobile  sort  and  the  Controller  sort  and  thus  the  signatures  of  the  engine-warning  events 
defined  in  the  event  theory  and  the  Automobile  aggregate  are  equivalent. 


event  Engine-Warning  is 
class  sort  Controller 
events 

engine-warning  ;  Controller,  Integer  — >  Controller 
end-class 

Figure  6.47  Engine- Warning  Event  Theory 


Communications  from  the  aggregate  to  the  components,  or  subcomponents,  is  much  simpler. 
Since  the  aggregate  includes  all  the  sorts,  operations,  and  axioms  of  all  of  its  components  and 
subcomponents  via  the  colimit  operations,  it  can  directly  reference  those  components  by  the  object¬ 
valued  attributes  declared  either  in  itself  (in  the  case  of  components)  or  in  its  components  (for 
subcomponents).  Because  an  aggregate  is  aware  of  its  configuration,  determining  the  correct  object¬ 
valued  attribute  to  use  is  not  a  problem. 
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class  Automobile  is 

import  AUTOMOBILE-AGGREGATE 

class  sort  Automobile 

sort-£ixiom  Automobile  =  Controller 

operations 

attr-equal  :  Automobile,  Automobile  —*■  Boolean 
attributes 

engine-obj  :  Automobile  — »  Engine-Class 
transmission-obj  :  Automobile  — »  Transmission-Class 
wheels-obj  :  Automobile  — »  Wheels-Class 
drives-assoc  :  Automobile  — +  Drives 
connected-assoc  :  Automobile  — »  Connected 
methods 

create-automobile  :  — *  Automobile 
events 

new-automobile  :  — ♦  Automobile 
engine-warning  :  Automobile,  Integer  -+  Automobile 
axioms 

axioms  omitted 
end-class 

Figure  6.48  Use  of  Sort  Axiom  in  Aggregate  Specification 


6. 7  Summary 

This  chapter  presented  a  theory-based  object  model  based  on  the  restricted  semantics  pre¬ 
sented  in  Chapter  V  of  the  Rumbaugh  OMT  object-oriented  specification  methodology.  It  defined 
the  basic  constructs  necessary  to  capture  an  object-oriented  specification  as  well  as  some  basic  re¬ 
lationships  that  must  hold  between  specific  types  of  object  classes.  These  basic  relationships  form 
the  laws  of  object  composition  and  define  the  relationships  between  classes  based  on  inheritance, 
association,  and  aggregation. 


An  object  class  is  defined  as  a  theory  presentation  with  operations  that  represent  attributes, 
methods,  events,  operations,  and  states  while  class  inheritance  is  specified  through  the  use  of  the 
import  block  and  subsorting  in  a  class  specification.  Links  are  defined  generically  as  a  class  of  objects 
that  relate  two  or  more  objects  from  other  classes.  While  link  specifications  are  not  exactly  the  same 
as  a  class  specification,  links  may  define  attributes  and  operations.  Associations  are  defined  simply 
as  a  set  of  link  objects.  A  unique  type  of  specification  is  introduced  to  define  an  aggregate  class.  An 
aggregate  specification  defines  a  diagram  of  class  specifications  and  the  morphisms  in  the  category 
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Spec.  The  classes  in  an  aggregate  specification  consist  of  the  aggregate’s  component  classes  and 
their  associations.  Finally,  event  theories  and  category  theory  operation  are  used  to  formally  define 
the  communication  paths  between  classes  in  a  domain  model  based  on  events  specified  in  the 
dynamic  model. 

The  next  chapter  builds  on  the  information  in  this  chapter  by  formally  defining  the  trans¬ 
formations  required  to  map  graphically-based  OMT  domain  models  into  the  formal  theory-based 
object  model  described  in  this  chapter. 
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VII.  Translation  to  Theory-Based  Specification 

7.1  Introduction 

In  the  previous  chapter,  a  theory-based  model  of  object-orientation  was  defined  based  on  con¬ 
cepts  from  Rumbaugh’s  OMT.  This  chapter  defines  the  transformation  rules  to  correctly  translate 
a  Rumbaugh  OMT  specification  into  its  theory-based  representation  based  on  the  theory-based 
object  model.  However,  because  there  is  no  standard  representation  for  OMT  specifications  other 
than  their  graphically-based  diagrams,  a  generic  OMT  (GOMT)  abstract  syntax  tree  is  used  (as 
defined  in  Appendix  A)  to  capture  the  components  of  the  OMT  diagrams  in  a  more  computation¬ 
ally  familiar  form.  This  GOMT  AST  was  developed  to  ensure  independence  from  any  particular 
front-end  tool.  As  defined  in  Appendix  D,  the  demonstration  system  developed  during  this  research 
translates  the  output  of  a  commercial  OMT-based  tool  into  the  GOMT  before  it  is  translated  into 
0-Slang  to  ensure  isolation  of  tool-dependent  concerns  from  the  actual  transformations.  Thus, 
the  transformations  in  this  chapter  define  translations  from  a  OMT  specification  captured  in  a 
GOMT  AST  into  an  0-Slang  abstract  syntax  tree.  These  transformation  rules  are  described  us¬ 
ing  first  order  algebraic  axioms  defined  over  the  GOMT  and  0-Slang  abstract  syntax  trees  using 
the  notation  and  names  defined  in  Appendix  C. 

The  correctness  of  these  transformations  is  established  in  Section  7.6  by  showing  that  the 
formal  semantics  of  each  model  (  as  defined  in  Chapter  V  )  is  preserved  by  the  transformations 
defined  in  Sections  7.2,  7.3,  and  7.4.  This  preservation  of  semantics  is  proved  by  defining  a  mapping 
from  the  theory-based  representation  in  O-Slang  to  the  formal  semantics  and  then  showing  that 
the  semantics  of  an  OMT  specification  is  equivalent  before  and  after  its  translation  to  O- Slang. 

In  this  chapter  I  use  the  convention  that  calligraphic  uppercase  letters  such  as  A  and  C  refer 
to  associations  and  classes  from  the  GOMT  AST  while  outlined  letter  A  and  C  refer  to  equivalent 
associations  and  classes  in  the  0-Slang  AST  (i.e.,  C  is  the  GOMT  class  corresponding  to  the 
0-Slang  class  C).  Dot  notation  is  used  to  refer  to  both  subobjects  and  attributes  of  objects  in  the 
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ASTs.  For  example  C.Name  would  refer  to  the  name  attribute  of  class  C  while  £,.C lass- Sort  is 
the  class-sort  subobject  which  itself  has  the  two  attributes  class-sort-id  and  inherited-sort-id.  The 
distinction  between  attributes  and  subobjects  are  clear  from  context  and  the  GOMT  and  0-Slang 
AST  definitions. 

Axioms  defined  in  this  chapter  are  written  as  quoted  strings  of  characters.  In  an  axiom,  all 
uppercase  strings  denote  actual  characters  in  the  string  while  object  and  attribute  names  denote 
placeholders  for  the  associated  values  of  those  objects  and  attributes.  For  example,  the  axiom 

^SIZE{c.Name-OBJ{X))  =  1” 

defines  a  string  where  the  value  of  c.Name  is  inserted.  Thus  if  c.Name  =  STUDENT,  the  axiom 
becomes 

'^SIZE{STUDENT-OBJ{X))  =  1” 

Within  axioms,  I  also  use  pattern  matching  placeholders,  “...”  to  match  an  arbitrary  sequence  of 
characters  in  an  axiom.  Thus  a  test 

if  ax  =“...  SIZE{IMAGE{A,X))  =  1  ...” 

returns  true  if  the  string  of  characters  “SIZE{IMAGE{A,X))  =  1”  is  a  substring  of  ax. 

Many  objects  in  the  GOMT  and  0-Slang  ASTs  define  sets  or  sequences  of  objects.  When 
forming  a  set  or  sequence,  general  set  former  notation  is  used.  The  set  S'  =  {x  |  P(x)}  denotes 
the  set  S  where  xSS  only  if  P{x)  is  true.  Sequences  are  formed  in  the  same  manner  using  square 
brackets  [x  \  P(x)]  instead  of  curly  braces.  Standard  set  and  sequence  operations  are  used,  with 
II  representing  the  concatenation  of  two  sequences. 

7.2  Object  Model  Translations 

A  GOMT  object  model  representation  consists  of  two  kinds  of  entities:  classes  and  asso¬ 
ciations.  This  section  discusses  the  translations  of  each  of  these  in  relation  to  the  OMT  object 
model. 
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7.2.1  Class  Translation.  The  object  model  of  a  GOMT  Class,  C,  consists  of  the  following 


items 


•  name 

•  set  of  superclass  names 

•  set  of  component  connections 

•  set  of  attributes 


With  the  exception  of  the  class  name,  all  items  are  optional.  The  following  transformations  convert 
a  GOMT  class,  C,  into  an  0-Slang  specification,  C. 


7. 2. 1.1  Class  Specification.  If  there  are  any  abstract  operations  in  C  then  C  generates 
an  abstract  class,  Cabstract-  If  there  are  no  abstract  operations  in  C,  C  generates  a  concrete  class, 
^.concrete  •  The  name  of  C  defines  the  name  of  C  as  well  as  the  name  of  its  class  sort.  All  other 
transformations  on  C  are  made  without  regard  to  whether  C  is  abstract  or  concrete. 


C  €  GOMT-DomainTheory.GOMT-Claas 

A  (V  (o)  0  €  C.GOMT-Op  ^  o.is-abstract  =  false) 

=>  3  (Cconcrete )  Cooncrete  €  O-Slang-DomainTheory 
A  Cconcrete  .Name  —  C.Name 

A  Cconcrete  -class-sort.classsort-id  =  C.Name  (OMT-1) 

C  6  GOMT-DomainTheory.GOMT-Class 

A  (3  (o)  o  €  C.GOMT-Op  A  o.is-abstract  =  true) 

=>  3  (CAbatract)  CAbetract  €  O-Slang-DomaiuTheory 
A  CAbatract  .Name  =  C.Name 

A  CAbatract  -dass-sort.dasssort-id  =  C.Name  (OMT-2) 


Prom  this  point  forward  in  the  translation  rules,  it  is  assumed  that  C  is  the  0-Slang  class 
generated  from  C  by  Rules  OMT-1  or  OMT-2  and  that  C  may  represent  either  an  abstract  class  or 
a  concrete  class. 


7. 2. 1.2  Superclasses.  The  classes  C  inherits  from  are  defined  by  a  set  of  superclass 
names.  In  O-Slang  this  requires  importing  each  superclass  and  defining  the  class  sort  of  C  to  be 
a  subset  of  each  of  the  superclass  class  sorts.  This  is  accomplished  by  placing  each  superclass  name 
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in  the  import  block  of  C  and  stating  that  the  class  sort  of  C  is  a  subsort  of  each  of  its  superclass 
class  sorts  as  shown  below  (where  si...Sn  are  superclass  names  in  C. superclass). 

class-sort  C.Name  <  si...s„ 

This  translation  is  defined  in  Rules  OMT-3  and  OMT-4 

s  6  C. Superclass  a  €  C.Import  (OMT-3) 

s  S  C. Superclass  s  €  C.class- sort. inherited-sort-id  (OMT-4) 

7.2.1. 3  Components.  If  C  has  component  connections  it  is  an  aggregate  object  and 
requires  the  creation  of  an  aggregate  class.  This  aggregate  class  is  then  imported  into  C  as  defined 
in  Section  7.2.3.  A  component  of  C  consists  of  the  following  items. 

•  name 

•  qualifier  (with  a  name  and  a  datatype) 

•  role 

•  multiplicity 

Besides  generating  an  aggregate  class,  each  component  connection,  c,  in  class  C  defines  an 
attribute  in  C  that  takes  the  class  sort  of  C  as  input  and  returns  a  set  of  component  objects.  As 
defined  in  Section  6.5,  a  component,  c,  becomes  an  object-valued  attribute  referencing  a  set  of 
objects  of  class  c.Name.  If  the  role  attribute  is  defined,  then  the  name  of  the  attribute  becomes 
the  role  name  given.  If  the  role  attribute  is  not  defined,  the  component  name  appended  with  the 
string  “-OBJ”  is  used  to  define  the  object-valued  attribute. 

c.Name-OBJ  :  C.Name  —>■  c.Name-Class 

or 

c.role  :  C.Name  —y  c.Name-Class 

The  formal  specification  of  this  transformation  is 
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c  e  C.Connection  =>  {attr-name{c),[C.Name],[c.Name-CLASS])  6  C.Attribute) 


(OMT-5) 


where  the  function  attr-name  is  defined  below. 

defined?{c.role)  ^  attr-name{c)  =  e.Role 

undefined? {c.role)  =>  attr-name{c)  =  c.Name-OBJ  '  ’ 

A  component  qualifier  is  used  to  discriminate  between  components  in  a  set.  According  to 
Section  6.5.2,  a  qualifier  becomes  an  attribute  of  the  component.  This  requirement  is  specified 
formally  in  Rule  OMT-6.  In  this  rule,  c  is  a  qualified  component  whose  0-Slang  class  specification 
is  Cq  and  whose  class  set  is  Cqj . 


c  €  C.Connection  A  c.Name  =  Cq  .Name  A  c.Name-CLASS  =  Cqs  .Name 
A  defined?(c.Qualifier)  => 

{{c.Qualifier.Name,  [c.Name],  [type(c.Qualifier)])  €  Q,  .Attribute 
A  {I MAGE,  [Cqs -Name,  c.Qualifier. Name],  [Cqa -Name])  &  Cqs  .Operation 
A  "IMAGE{C,Q)  =  {X  I  X  €  C  t\c.Qualifier.Name{C)  =  Q}”  £  Cqs -  Axiom) 


(OMT-6) 


where  the  function  type  is  defined  as 

defined?{c.datatype)  =>  type(c)  =  c.Datatype  .  . 

undefined? (c.datatype)  =>•  type{c)  =  c.Name  ^  '  ' 

According  to  Section  6.5,  a  class,  C,  with  components  also  includes  an  attribute  for  each 
association  whose  components  are  all  components  (or  subcomponents)  of  C.  Assuming  there  exists 
such  an  association.  A,  the  attribute  takes  the  form  show  below.  Because  of  the  intricacies  of 
determining  exactly  when  this  is  applicable,  the  actual  rule  for  this  transformation  is  defined  in 


Rule  OMT-30. 


AName- ASSOC  :  C.Name  — >  AName 


The  component  class  named  c.Name  and  its  class  set  named  c.Name-CLASS both  assumed 
to  exist.  As  discussed  above,  an  object  with  components  generates  an  aggregate  specification.  This 
aggregate  specification  includes  the  definition  of  all  lower-level  components  and  must  be  imported 
into  C.  This  requirement  is  defined  formally  in  Rule  OMT-7. 
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(3  (c)  c  €  C. Connection)  =>  C.Name-AGGREGATE  g  CJmport 


(OMT-7) 


The  multiplicity  of  a  component  defines  how  many  of  each  component  may  be  part  of  the 
aggregate  class  C.  As  defined  by  Rumbaugh,  these  multiplicities  include: 

•  One 

•  Many 

•  Plus  (with  an  integer) 

•  Optional 

•  Specified  (with  a  set  of  Spec-Ranges  which  have  one  or  two  integers  indicating  the  range  of 
multiplicities) 

where  a  multiplicity  of  One  allows  only  one  component,  a  multiplicity  of  Many  allows  zero  or 
more  components,  Plus  allows  the  user  to  specify  a  minimum  number  of  components.  Optional 
allows  exactly  zero  or  one  component,  and  Specified  allows  the  user  to  specify  the  exact  number  or 
range  of  components  allowed  to  be  part  of  the  aggregate.  Therefore,  as  defined  in  Section  6.4.1, 
the  multiplicity  of  component  c  defines  an  0-Slang  axiom  specifying  the  allowable  number  of 
components  that  may  be  part  of  C.  Generally,  the  axioms  defined  by  the  first  four  multiplicities 
(One,  Many,  Plus,  and  Optional)  are  simple  and  are  given  in  0-Slang  syntax  below. 


One 

Many 

Plus 

Optional 


SIZE{attr-name(c){0))  =  1 
SI Z E{attr-name{c){0))  >  0 
SI ZE(attr-nanie{c){0))  >  c.Plus. integer 
SIZE{attr-name{c){0))  =  0  V  SI ZE[attr-name{c){0))  =  1 


However,  if  the  component  is  qualified,  the  multiplicity  is  defined  on  the  qualified  image  operation 
defined  in  the  component  class  by  Rule  OMT-6.  The  format  of  the  qualified  multiplicity  axiom  is 
show  below. 


One 

Many 

Plus 

Optional 


SIZE{IMAGE{attr-name{c){0),q))  =  1 
SIZE{IMAGE{attr-name{c){0),q))  >  0 
SIZE{IMAGE{attr-name{c){0),q))  >  c.Plus. integer 

SIZE{IMAGE(attr-name{c){0),q))  =  Qy  SIZE{IMAGE{attr-name{c){0),q))  =  1 
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These  requirements  are  formalized  in  the  following  axioms. 


c  S  C.Connection  A  c.Mult  —  One  => 

{{undefined?{c.Qualifier)  =>  “SIZE{attr-name{c){X))  —  1”  €  C.Axiom) 

{defined?  {c.Qualifier) 

^  “SIZE{IMAGE{attr-name{c){X),Q))  =  1”  e  C. Axiom))  (OMT-8) 

c  €  C.Connection  A  c.Mult  =  Many 

{{unde fined? {c.Qualifier)  “SIZE{attr-name{c){X))  >  0”  e  C.Axiom) 

{defined?  {c.Qualifier) 

=>  “SIZE{IMAGE{attr-name{c){X),Q))  >  0”  6  C. Axiom))  (OMT-9) 

c  G  C.Connection  A  c.Mult  =  Plus  ^ 

{{undefined?  {c.Qualifier) 

=>  ‘'SI ZE{attr-name{c){X))  >  c.Plus. integer"  €  C.Axiom) 

{defined? {c.Qualifier) 

=>  “SIZE{IMAGE{attr-naTne{c){X),Q))  >  c.Plus. integer”  e  C. Axiom))  (OMT-10) 

c  G  C.Connection  A  c.Mult  —  Optional  ^ 

{{unde  fined?  {c.Qualifier) 

=>  “SIZE{attr-name{c){X))  =  0  V  SI ZE{attr-name{c){X))  =  1”  G  C.Axiom) 
{defined?  {c.Qualifier) 

=»  “SIZE{IMAGE{attr-name{c){X),Q))  =  0 

V  SIZE{IMAGE{attr-name{c){X),Q))  =  1”  G  CAxiom))  (OMT-11) 


Generating  the  axiom  for  a  Specified  multiplicity  is  more  complex.  It  may  be  used  to  specify 
either  an  exact  number,  a  range  of  numbers,  or  a  combination  of  both.  Each  Specified  multiplicity 
may  have  a  number  of  specified  ranges.  For  each  specified  range,  s,  if  only  one  value  {valuel)  is 
specified  in  an  unqualified  Specified  multiplicity  then  the  subaxiom 

SIZE{attr-name{c){0))  =  s.Valuel 

is  generated  as  part  of  the  overall  specified  axiom.  However,  if  two  values  {valuel  and  value2)  are 
specified,  then  the  multiplicity  defines  a  range  as  shown  in  the  following  subaxiom. 

SIZE{attr-name{c){0))  >  s.Valuel  A  SI ZE{attr-name{c){0))  <  s.Value2 
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Because  a  user  may  specify  multiple  Specified  values  or  ranges,  the  axioms  generated  for  each 
Specified  multiplicity  must  be  disjuncted  to  create  a  single  axiom  defining  the  possible  multiplicities 
of  a  component  c  as  shown  below. 


c  €  C.Connection  A  c.Mult  =  Specified  => 

{(undefined7{c.Qualifier) 

OR{{ax  I  s  €  c.Mult  A 

(defined? {3.value2)  ^  ax  =  “SIZE(attr-name(c)(X))  >  a.valuel 
A  SI ZE(attr-name(c){X))  <  s.value2”) 

A  (undefined7(s.value2)  ax  =  “SIZE{attr-name(c)(X))  =  s.valuel")}) 

£  C.  Axiom) 

(de  fined? (c.Qualifier)  => 

OR{{ax  I  s  £  c.Mult  A 

(defined? (a. value2)  ^  ax  =  “SIZE(IMAGE(attr-name(c)(X),Q))  >  a.valuel 
A  SIZE(JMAGE(attr-name(c)(X),Q))  <  a.value2”) 

A  (undefined? (a.value2) 

^  ax  =  “SIZE(IMAGE(attr-name(c)(X),Q))  =  s.vol'uel”)}) 

eC.Axiom))  (OMT-12) 

where  OR  is  a  function  that  returns  a  single  axiom  that  is  the  logical  disjunction  of  all  axioms  in 
the  input  set. 


7.2. 1.4  Attributes.  Each  attribute,  a,  in  C  is  either  a  normal  or  derived  attribute. 
Each  attribute  in  the  GOMT  AST  consists  of  the  following  items. 

•  name 

•  datatype  (optional) 

•  expression  (optional) 

Each  normal  attribute,  anorm,  in  defines  an  attribute  declaration  in  C  of  the  form: 

Q^norm -Name:  C.Name  type(a) 

where  type  is  the  function  defined  in  Equation  7.2. 

An  expression  of  a  normal  attribute  is  interpreted  as  the  initial  value  computation  for  that 
the  attribute.  Therefore,  each  normal  attribute  expression  defines  an  axiom  in  the  axiomblock  of 
C  of  the  form 
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a„oTm-NaTne{CREATE-C.NaTne(j)araTneters))  —  anorm-expression 


where  CREATE-C.Name{parameters)  is  the  create  object  function  automatically  created  when 
C  is  defined.  Parameters  of  the  create  function  are  defined  by  the  dynamic  or  functional  model  as 
defined  in  Rule  OMT-75  or  OMT-85.  If  no  dynamic  model  exists  and  create  is  not  specified  in  the 
functional  model  then  it  is  assumed  there  are  no  parameters  to  the  create  function.  If  the  create 
function  is  specified  in  the  dynamic  model,  then  the  parameter  number  and  types  defined  in  the 
dynamic  model  are  used. 

The  formal  transformations  required  for  normal  attributes  are  shown  in  Rule  OMT-13. 


a  €  C.NormAttr 

=>  {{a. Name,  [C.Name],  [tj^pe(Q:)])  €  C.Attribute 
A  defined! {a. expression)  => 

“a.Name(CREATE-C.Name(C.Name,create-domain(C))) 

=  a.expression”  £  C.Axiom)  (OMT-13) 


where  the  function  create-domain  is  defined  as 

(3  (t,  a)  r  £  C. Transition  Aa  £  r. Action  A  a. Name  =  GREAT  E-C. Name) 

=>  create-domain{C)  =  domain(a)  . 

-i(3  (r,  a)  r  £  C. Transition  A  a  £  r.  Action  A  a. Name  =  GREAT  E-C. Name)  '  ' 

=>  create-domain{C)  =  [| 

and  the  function  domain  is  defined  as  the  following  sequence. 

domain(a)  =  [type(j[>)  |  p  £  a. Parameter]  (7.4) 

Because  a  derived  attribute  calculates  its  valued  based  on  normal  attributes,  each  derived 
attribute,  aderivedt  in  C  defines  an  operation  declaration  in  C  of  the  form 

Oderived-Name  :  C.Name  — *  type{a) 

where  again,  type  is  defined  in  Equation  7.2.  The  user  may  define  the  value  of  a  derived  attribute 
in  one  of  two  ways:  via  a  functional  model  decomposition  or  by  providing  an  expression  in  the 
attribute  definition.  A  functional  model  defines  a  set  of  axioms  as  described  in  Section  7.4.  If  the 
user  provides  an  expression,  the  expression  becomes  an  axiom  in  the  axiom  block  of  C,  .  These 
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expressions  are  assumed  to  have  the  correct  0-Slang  syntax  and  semantics  to  compute  the  derived 
attribute  value.  The  axiom  generated  is  shown  below. 

^devivcd  .eiCpT'eSSlOTl 

The  formal  transformations  required  for  derived  attributes  are  specified  in  Rule  OMT-14 
where  create-domain  is  defined  as  in  Equation  7.3. 

a  €  C.DerivedAttr  =>  {a. Name,  [C.Name],  [type{a)])  G  C.Operation 
A  {defined! {a. expression)  ‘^a.Name{C.Name)  =  a.expression”  G  C. Axiom)  (OMT-14) 

7.2. 1.5  Operations.  Operations  are  transformed  in  the  functional  model  as  defined 
in  Section  7.4  or  via  special  operation  definitions  as  defined  in  Section  7.5.  The  only  exception  to 
these  rules  is  the  operation  attr-equal.  The  attr-equal  operation  determines  if  two  objects  of  the 
same  class  have  identical  non-state  attribute  values.  Therefore,  if  a  class,  C,  has  normal  attributes, 
it  must  have  an  attr-equal  operation.  The  signature  of  the  operation  is  shown  below. 

attr-equal :  C.Name,  C.Name  —*  Boolean 

Assuming  C  has  normal  attributes  Q;i...a„,  the  axiom  defining  the  attr-equal  operation  takes  the 
form 


attr-equal{ci,C2)  =  ai(ci)  =  ai(ci)  A  ...  A  a„(ci)  =  a„(ci) 


Formally,  the  transformations  that  create  the  attr-equal  operation  and  its  definition  are 
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(3  (a)  a  e  C.NormAttr)  =>  (ATTR-EQUAL,  [C.Name,C.Name],  [Boolean])  6  C.Operation 
A  “ATTR-EQU AL{0i,02)  =  attr-compare{C)"  6  C.Axiom  (OMT-15) 

where  the  function  attr-compare  is  defined  as  the  logical  conjunction  of  equations  between  two 
attributes  of  two  objects,  Oi  and  O2  as  defined  below  in  Equation  7.5.  The  AND  function  is 
defined  similar  to  the  OR  function  as  the  conjunction  of  a  set  of  axioms. 

attr-compare(C)  =  AND{{“a{Oi)  =  0(02)”  1  a  €  C.NormAttr})  (7.5) 

7.2.1. 6  Methods.  Because  of  my  approach  to  using  OMT  in  this  research,  methods 
are  defined  either  in  the  dynamic  or  functional  models;  however,  if  there  is  no  dynamic  model  and 
a  create  process  is  not  defined  in  the  functional  model,  a  default  create  method  must  be  defined. 
A  default  create  method  takes  no  inputs  and  produces  a  value  of  the  class  sort  of  of  C  as  shown 
below. 

CREATE-C.Name  C.Name 

The  default  definition  of  the  create  method  is  shown  below. 

SI ZE{C .Transition)  =  0  A  (V  {p)  p  €  processes{C)  p.Name  CREATE-C.Name) 

=>  {CREATE-C.Name,  Q,  [C.ATame])  e  C.Method  (OMT-16) 

In  Rule  OMT-16,  the  function  processes  returns  the  set  of  all  subprocesses  of  a  class  or  a  process 
in  a  class  as  defined  below. 

processes{x)  =  {p  \  p  €  Process{x)  ,  . 

pi  £  processes{x)  Ap  €  Processip)  ^  ‘  ' 

The  default  values  of  normal  attributes  are  used  to  create  the  definition  of  create.  For  each 
normal  attribute,  a,  in  C  with  a  defined  default  value  expression,  the  following  axiom  is  generated 
as  defined  in  Rule  OMT-13. 

a.Name{CREATE-C.Name{))  =  a.expression 
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7. 2. 1.7  Events.  When  a  default  create  process  must  be  created  as  defined  above,  a 
corresponding  new  event  must  also  be  created  to  invoke  the  create  method.  This  new  event  has  the 
exact  same  domain  and  range  as  the  create  method 

NEW-C.Name  >  C.Name 

and  its  only  axiom  “invokes”  the  create  method  as  shown  below. 

ATTR-EQUAL{NEW-C.Name{),CREATE-C.Name{)) 

These  two  definitions  are  captured  in  the  following  transformation  rules. 

SI ZE{C.Transition  =  0)  A  (V  (p)  p  e  processes{C)  p.Name  ^  CREATE-C.Name) 

=>  {{NEW-C.Name,  0,  [C.Name])  e  C.Event  (OMT-17) 

SI ZE{C. Transition  =  0)  A  (V  (p)  p  e  processes{C)  p.Name  CREATE-C.Name) 

^  “ATTR-EQUAL{NEW-C.Name{),CREATE-C.Name{))”  6  C. Axiom)  (OMT-18) 

where  processes  is  defined  in  Equation  7.6. 

7.2.2  Class  Sets.  Each  class  C  generates  a  second  specification  called  the  class  set,  Q 
that  defines  a  set  of  objects  of  type  C.  The  name  C  defines  the  name  of  Q  as  well  as  the  name  of  the 
class  sort  of  Cj .  The  string  “-CLASS”  is  simply  appended  to  the  name  of  the  class  set  specification 
and  class  sort.  To  explicitly  state  that  Q  defines  a  set  of  objects  of  type  C,  a  contained-in  name  is 
defined  as  the  name  of  the  defining  class.  The  formal  specification  of  the  transformation  is  shown 
in  Rule  OMT-19. 

C  e  GO MT-DomainTheory. Class  =>  3  (Cj)  Cs  6  0-Slang-DomainTheory 
A  Cs  .Name  =  C.Name-CLASS 
A  Cs  .class-sort. classsort-id  =  C.Name-CLASS 

A  Cs  .contained-in  =  C.Name  (OMT-19) 

7.2. 2.1  Class  Set  Superclasses.  The  set  of  superclass  names  of  C  defines  the  classes 
from  which  C  inherits.  As  defined  in  Definition  6.2.1,  the  class  set  of  the  superclasses  of  C  must 
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also  be  imported  into  the  class  set  of  C.  This  is  accomplished  by  placing  each  superclass  name  in 
the  import  block  of  C«  as  defined  in  Rule  OMT-20. 

3  e  C. Superclass  ^  s-CLASS  €  Cs  .Import  (OMT-20) 

7. 2. 2. 2  Class  Set  Event.  Each  event  in  class  C  defines  a  class  event  in  Q.  These 
class  events  have  the  same  signature  as  the  events  from  class  C  with  the  class  sort  of  C  replaced 
by  the  class  sort  of  Q .  The  formal  transformation  is  shown  below  where  the  function  rest  returns 
all  items  in  a  sequence  but  the  first  item. 

e  =  {name,  domain,  range)  €  C.Event  => 

{name,[C.Name-CLASS\  ||  rest{domain),[C.Name-CLASS]  ||  rest{range)) 

e  Cs  .Event  (OMT-21) 

The  purpose  of  class-level  events  are  to  distribute  the  object-level  event  to  each  object  in  the 
class  set.  Thus  for  each  event  in  Cj,  an  axiom  is  added  via  the  following  transformation. 

e  =  {name,  domain,  range)  €  C.Event  ^ 

'N  {C  ■.c.Name,CC  :c.Name-CLASS)  C  eCC<=)- 
e.N ame{C, parameter s{e))  £  e.Name{CC, parameter s{e)y''  £  Cs. Axiom  (OMT-22) 

where  parameters  is  defined  as 

parameters{e)  =  [uniqtie{x)  |  x  £  rest{e.domain)]  (7.7) 

and  unique  is  a  function  that  returns  a  unique  symbol  name  based  on  the  input  symbol. 

In  Section  6.2.4,  the  Theory-Based  Object  Model  requires  each  class  to  define  a  new  event 
that  causes  the  creation  of  a  new  object.  Because  the  class  sort  of  a  class  set  is  a  set,  a  new  class 
set  object  is  simply  an  empty  set.  This  requirements  is  captured  by  defining  a  new  event 

NEW-C.Name-CLASS  C,.Name-CLASS 

with  the  axiom  defining  a  new  class  set  to  be  empty. 

NEW-C.Name-C  LASSO  =  EMPTY-SET 
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Formally,  these  definitions  are  captured  by  the  following  transformation  rule. 


Cj  S  O-Slang-DomainTheory 

{NEW-C.Name-CLASS,  Q,  [CJVame-CL^55])  G  C^. Event 
A  "NEW-C-Name-CLASSO  =  EMPTY-SET’  G  C  .Axiom  (OMT-23) 

7.2.3  Aggregates.  As  discussed  in  Section  7.2.1,  each  class  C  with  components  defines  an 
aggregate  class  Ca.  This  aggregate  class  has  a  special  form  that  defines  the  colimit  of  a  diagram. 
In  this  section  C  denotes  the  GOMT  class  that  generates  C,  the  class  specification,  and  Ca,  the 
aggregate  specification  in  0-Slang.  When  generating  the  aggregate  class,  the  name  of  Ca  is 
defined  by  simply  appended  the  string  “-AGGREGATE”  to  the  name  of  the  C.  Rule  OMT-24 
formally  defines  this  translation  requirement. 

c  G  C. Connection  =»  3  (Ca)  Ca  G  0-Slang-DomainTheory 

A  Ca  .Name  =  C. Name- AGGREGATE  (OMT-24) 

The  diagram  of  specifications  and  specification  morphisms  is  defined  by  a  set  of  nodes  (spec¬ 
ifications)  and  a  set  of  arcs  (specification  morphisms).  These  nodes  correspond  to  all  classes,  data 
types,  associations,  and  event  theories  referenced  by  a  class,  or  any  of  its  superclasses  or  compo¬ 
nents.  A  specification  is  in  the  node  set  of  Ca  if  it  is  one  of  the  following. 

1.  A  specification  imported  in  C. 

2.  A  component  of  C. 

3.  The  class  set  specification  of  a  component  of  C. 

4.  The  aggregate  specification  of  a  component  of  C. 

5.  Any  specification  imported  by  nodes  in  Ca. 

6.  An  association  specification  whose  connections  are  all  nodes  in  Ca- 

7.  Any  specification  imported  by  components  of  two  or  more  nodes  of  Ca. 

8.  A  unique  TRIV  specification  is  added  to  the  node  set  for  each  connection  in  an  association 
specification  CA-Node. 

9.  An  event  theory  defining  the  communication  between  nodes  in  Ca- 

10.  A  broadcast  theory  defining  the  communication  between  multiple  nodes  in  Ca. 
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The  first  seven  of  these  transformations  are  defined  next.  Item  8,  the  creation  of  a  unique 
TRIV  specification,  is  created  as  part  of  Rule  OMT-38  while  the  event  and  broadcast  nodes  and 
arcs  are  more  complex  and  are  defined  in  Section  7.2.3. 1.  The  formal  transformation  rules  for 
determining  the  set  of  nodes  in  an  aggregate  are  expressed  in  Rules  OMT-25  through  OMT-39. 


s  €  CJmport  =>  {s,  s)  €  C\.Node  (OMT-25) 

s  €  C.Connection  {s. Name, s. Name)  S  C^-Node  (OMT-26) 

s  €  C.Connection  =>■  {s.Name-C LASS,  s.Name-C LASS)  6  Cx.Node  (OMT-27) 

s  €  C.Connection  A  s.Name  =  C' .Name  A  (3  (c)  c  €  C' .Connection) 

=>  {C' .Name-AGGREGATE,C' .Name-AGGREGATE)  e  C^.Node  (OMT-28) 

(x,  s.Name)  e  Ca. Node  A  si  e  s. Import  ^  (si,  si)  6  Ca. Node  (OMT-29) 

A  €  GOMT-DomainTheory.Assoc  A  (V  (c)  c  €  A.Connection  {x,c.Name)  6  Ca. Node 
^  {{A. Name,  A. Name)  €  CA.Node) 

{A.Name-ASSOC,  [CATome],  [M.ATome])  €  C.Attribute)  (OMT-30) 

{z,  si.Name),  {y,  s^.Name)  6  CA.Node  Ax  €  imports{s\)  Ax  £  imports{s2) 

=>  {x,x)  6  CA.Node  (OMT-31) 


where  the  function  imports  recursively  defines  the  set  of  all  imports  of  a  given  class  as  shown  below. 


defined! (c.Node)  imports{c)  =  {s  |  s  €  imports{x)  V  {x,  s.Name)  G  c.Node) 
defined?{c. Import)  =>■  imports{c)  =  {s  |  s  €  c.Import  V  (s  G  imports{x)  A  x  G  c.Import)} 

(7.8) 

and  are  critical  to  correctly 
rii ,  Ti2  in  the  node  set  of  Ca 

1.  rii  is  directly  or  indirectly  imported  by  n2 

2.  Til  is  a  component  of  n^ 

3.  rii  is  superclass  of  712 

4.  712  =  771-CLASS 

5.  Til  =  712-AGGREGATE 

6.  Til  =  712-link 


The  morphisms  between  nodes  of  C  define  the  set  of  arcs  in  C 
defining  the  colimit  of  the  diagram.  An  arc  is  in  the  arc  set  of  C  if  for 
one  of  the  following  holds. 
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7.  712  is  a  connection  of  tii  ,  an  association 

8.  rii  is  an  event  theory  received  by  712  (or  a  subcomponent  of  772) 

9.  Til  is  an  event  theory  sent  by  a  component  of  712 

Once  the  nodes  of  an  aggregate  are  known,  the  arcs  may  be  computed.  Once  again,  the  first 
seven  items  above  are  straightforward  and  discussed  below,  while  defining  the  arcs  between  event 
and  broadcast  theories  is  more  complicated  and  is  discussed  separately  in  Section  7.2.3.I.  The  first 
seven  transformations  may  be  expressed  formally  as  shown  below.  In  these  transformations,  tii 
and  712  are  classes  in  the  0-Slang  Domain  Theory  whose  names,  ni.Name  and  nz-Name,  are  in 
the  node  set  of  aggregate  Ca  and  Cni  and  C„2  represent  the  GOMT  classes  that  generated  classes 
Til  and  712.  The  transformations  to  define  the  set  of  arcs  for  an  aggregate  Ca  are  shown  below. 

{x,ni.Name),  {y,  ni.Name)  €  C^.Node 

A  m.Name  €  irnports(n2)  {{x, ni. Name),  {y, rii. Name),  {})  e  Cji.Arc  (OMT-32) 

ni.Name  €  imports(n2) 

=>■  {{ni. Name, ni. Name),  (n2.Name,n2.Name),{})  6  Ca. Arc  (OMT-33) 

m.Name  €  n2.ClaasSort. Inherited-Sort-Id 

=>  {{m. Name, m. Name),  (n2.Name,n2.Name),{})  S  Ca. Arc 
A  {{tii .Name-CLASS,  m  .Name-CLASS), 

{n2.Name-CLASS,n2.Name-CLASS),{})  £Ca. Arc  (OMT-34) 

n2.Name  —  m. Name-CLASS 

=>  {(m.Name,  m.Name),  {n2. Name, n2. Name),  {})  €  Ca. Arc  (OMT-35) 

m.Name  =  n2. Name- AGGREGATE 

=>  {(m. Name, m. Name),  {n2. Name,n2. Name),  {})  e  Ca.At-c  (OMT-36) 

m.Name  =  n2.N  ame-LI  N  K 

{{m. Name, m. Name),  {n2. Name, n2. Name), {})  €  Ca. Arc  (OMT-37) 

c  €  Cni. Connection  A  c.Name  =  n2.Name  A  TRIVx  =  {unique{TRIV),  TRIV)  => 

{{defined?  {n2.role) 

=>  {TRIVx,  {m.Name-LINK,m.Name-LINK),{E  n2.role})  €  Ca. Arc) 

A  {undefined? {n2. role) 

=>  {TRIVx,  {m. N ame-LI NK,m.N ame-LI NK),  {E  attr-name{n2)})  £  Ca .Trc) 

A  {TRIVx,  {n2. Name, n2. Name),  {E  —*■  n2.Name})  €  Ca.At’c 

A  TRIVx  e  Ca. Node)  (OMT-38) 
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7.2. 3.1  Communication  Theories  in  Aggregates.  When  discussing  event  a.nd  broad¬ 
cast  theories,  it  is  often  difficult  to  determine  exactly  when  to  include  them  in  aggregate  nodes  and 
arcs.  If  there  is  only  one  class  that  receives  an  event,  the  problem  is  not  difficult.  Event  theories 
become  nodes  in  an  aggregate  when  (1)  a  class  which  is  a  node  in  the  aggregate  imports  the  event 
theory  (the  class  sends  the  event),  or  (2)  when  the  nodes  of  an  aggregate  include  both  a  sending 
class  and  a  receiving  class.  The  formal  transformation  rules  of  this  simple  case  are  shown  below 


e  €  0-Slang-DomainTheory. Event  A  size(receive3(e))  =  1 

A  (ni,ni),  (712,712)  €  Ca. Node  A  Tii  €  comp-sends{e)  A  712  £  comp-receives{e) 

=>  ({e. Name, e. Name)  €  Cx-Node 

A  {{e.Name,e.Name),{ni,ni),{})  ^Cx-Arc 

A  {{e.Name,e.Name),(n2,n2),{domain-map{e,n2)})  £  Ca. Arc)  (OMT-39) 


where  domain-map  is  the  mapping  of  sorts  in  the  domain  of  the  equivalent  event  signatures  in  ci 
to  the  sorts  of  the  domain  of  event  signature  in  C2  as  defined  below  (the  function  index  is  the  index 
of  the  sort  symbol  within  a  sequence  -  the  domain-ident  of  the  event) 


domain-map{ci,C2)  =  {“ai-+a2”  |  ai  €  ei. domain-ident  A  02  £  62 -domain-ident 

A  index  {a  i,ei. domain-ident)  =  index{a2,  e2.domain-ident)  (7.9) 

A(ei  e  Cl. Event  A  e2  £  C2. Event  A  ei. Name  =  e2.Name)} 

and  receives,  sends,  comp-receives,  and  comp-sends  are  functions  that  define  a  set  of  classes  who 
send/receive  a  given  event  or  who  have  components  who  send/receive  a  given  event. 


receives(e)  =  {c.Name  \  c  £  GO MT-DomainTheory. Class 
A  t  £  c.Transition  A  e.Name  =  t.Name} 

sends{e)  =  {c.iVaTTie  |  c  €  GOMT-DomainTheory. Class 

A  t  £  c.Transition  Aa  £  t.Action  A  e.Name  =  a.  Action.  Name} 

comp-receives{e)  =  {c.A^aTTie  |  x  £  receives(e)  A  (x  £  components-of(c)  V  x  =  e.Name)} 

comp-sends(e)  =  {e.Name  \  x  £  sends{e)  A{x  £  component  s-of{c)  V  x  =  e.Name)} 


(7.10) 

(7.11) 

(7.12) 

(7.13) 


The  function  components-of  defmes  a  set  consisting  of  the  names  of  all  classes  which  are  components 
or  sub-components  of  a  given  class  as  defined  below. 
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component s-of(c)  =  {x.Name  |  x  6  c.Connection  ,  , 

V  (x  e  components-of(y.Name)  Aye  components-of{c))}  ^ 

When  there  is  more  than  a  single  class  that  receives  an  event,  the  computation  of  aggregate 
nodes  and  arcs  becomes  more  difficult.  As  described  in  Section  6.6,  a  broadcast  theory  is  defined  to 
send  an  event  to  multiple  classes.  Determining  where  to  place  this  broadcast  theory  is  the  problem. 
According  to  the  Theory-Based  Object  Model,  the  broadcast  theory  should  be  placed  in  the  lowest- 
level  aggregate  in  the  domain  theory  that  includes  (possibly  as  components  or  subcomponents  of 
nodes  in  the  aggregate)  all  of  the  sending  classes  and  all  of  the  receiving  classes. 

When  the  appropriate  aggregate  has  been  found,  a  broadcast  theory  is  created  as  defined 
in  Section  6.6.  The  broadcast  theory  imports  the  appropriate  event  theory  and  creates  a  unique 
event  theory  for  each  receiving  class.  An  import  arc  is  defined  between  each  sending  class  and  a 
single  event  theory,  which  in  turn  has  an  import  arc  between  it  and  the  broadcast  theory.  While 
the  sending  classes  may  share  a  single  copy  of  an  event  theory  specification  in  order  to  link  to  the 
broadcast  theory,  each  receiving  class  must  have  a  unique  event  theory  specification  that  is  mapped 
to  the  event  in  the  broadcast  theory  for  that  particular  receiving  class.  The  transformations  are 
defined  formally  below.  Rule  OMT-40  defines  the  broadcast  theory  while  Rule  OMT-41  defines  the 
appropriate  nodes  and  arcs  in  the  aggregate. 
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e  e  0-Slang-DomainTheory. Event  A  size{receives(e))  >  1 
A  event  6  e. Event 

A  (c  e  receive3{e)  c  €  components-of^Ch)) 

A  (c  €  sends{e)  =>•  c  e  components-of{C\)) 

A  -i(3  (o)  o  €  com,ponents-of{C\)hdefined1{a.Node) 

A  (c  S  receives{e)  =>  c  6  components-of{CA)) 

A  (c  e  3ends{e)  ^  c  €  com.p(ments-of{C\))) 

Q;  e  O- Slang- DomainT hear y 
A  Cs-Name  =  e.Name-MULT 
A  Ca. Class-Sort. Class-Sort-Id  =  e.Name-SORT 
A  e.Name  €  -Import 
A  (c  €  receives  (e) 

((e.ATame,  [c.A^ame]  ||  <iomam(eveTii),  [c.JVame])  6  Event 
A  (c.ATame-OBJ,  [e.JVame],  [c.ATame])  €  Ca -Attribute 
A  “c.Name-OBJ(e.Name(e.Class-Sort.Class-Sort-Id,domain{event)) 

=  e.Name{C -N ame-OB  J{e.Class-Sort. Class-Sort-Id),  domain{event))) 

6  .Axiom))  (OMT-40) 


e  €  0-Slang-DomainTheory. Event  A  size(receives(e))  >  1 

A  emult  €  0-Slang-DomainTheory. Event  A  e.Name-MULT  =  emult.Name 
A  (c  €  receives{e)  =?>  c  €  components-ofiCA.)) 

A  (c  €  sends(e)  ^  c  6  components-of(CA)) 

A  -1(3  (a)  a  €  components-of{CA)  A  defined? (a. Node) 

A  (c  e  receives(e)  =>  c  €  components-of{CA)) 

A  (c  €  sends(e)  =►  c  €  components-of{CA))) 

=>  {emult.Name,  emult.Name)  G  CA-Node 

A  (c  G  {comp-receives{e)  fl  {n  j  (n,  x)  G  CA.ATode}) 

A  ev  G  c.Event  A  ev.Name  =  e.Name 

=>•  (x  =  unique{e.Name)  A  {x, e.Name)  G  CA-Node 

A  {{x, e.Name),  {e.Name, e.Name), domain-map{e,c))  G  Ca .Arc 
A  ((x,  e.Name),  {emult.Name,  emult. Name),domain-map{e,  emult)) 

GCa.Axc))  (OMT-41) 


7.2. 3.2  Domain  Theory  Aggregate.  To  ensure  that  all  classes,  associations,  and 
events  are  unified  in  the  domain  theory,  an  overall  domain  theory  aggregate  is  created  that  combines 
all  top-level  classes  into  a  single  specification.  This  is  accomplished  by  creating  a  top-level  aggregate 
with  all  top-level  classes  as  nodes.  Then,  Rules  OMT-25  through  OMT-41  add  additional  nodes 
(associations,  common  imports,  and  event  and  broadcast  theories)  to  the  aggregate  and  compute 


7-19 


the  necessary  arcs.  The  top-level  classes  are  those  classes  that  are  not  components  of  any  other 
class  as  defined  by  Equation  7.15.  The  function  top-level  takes  a  GOMT  domain  theory  and  returns 
a  set  of  nodes. 

top-level{DT)  =  {(c,c)  \  cG  DT. Class}  \{{c,c)  \  c.Name  &  k.Connection  A  k  €  DT.Class}  (7.15) 

Thus,  for  each  GOMT  domain  theory,  a  top-level  aggregate  is  automatically  created  with  an 
initial  set  of  top-level  nodes  as  defined  in  Rule  OMT-42. 


3  (Ca)  Ca  €  0-Slang-DomainTheory 
A  Cx.Name  =  DOMAIN-THEORY 

A  Cf^.Node  =  top-level{GOMT-DomainTheory)  (OMT-42) 


7.2.4  Association  Translation.  A  GOMT  association.  A,  consists  of  the  following  items 

•  name 

•  set  of  class  connections 

•  set  of  attributes 

•  set  of  operation  definitions 

Each  GOMT  association.  A,  defines  two  0-Slang  specifications,  a  link  specification,  Al, 
and  an  association  specification  A  where  the  association  specification  defines  a  set  of  link  objects 
similar  to  a  class  set  specification.  The  name  of  A  defines  the  names  and  class  sorts  of  A  and 
The  formal  rules  for  this  transformation  are  shown  below. 


A  €  GOMT-DomainTheory. Assoc  Ai,  €  0-Slang-DomainTheory 

A  Ar.lVame  =  A.Name-LINK 

A  Al. Class-Sort. ClassSort-Id  =  A.Name-LINK  (OMT-43) 

A  €  GOMT-DomainTheory. Assoc  =>  A  G  O-Slang-DomainTheory 
A  A.Name  =  A.Name 
A  A.Class-Sort.ClassSort-Id  —  A.Name 

A  A.Link-Class  =  A.Name-LINK  (OMT-44) 


The  association  specification  defines  a  set  of  links  along  with  the  association  multiplicity 
defined  by  the  association  connections.  Associations  do  not  have  attributes  or  operations.  GOMT 
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operations  and  attributes  are  used  to  define  the  link  attributes  and  operations  only.  Therefore,  the 
definition  of  the  association  relies  solely  on  its  set  of  class  connections.  These  connections  have  four 
components. 

•  name 

•  qualifier  (with  a  name  and  a  datatype) 

•  role 

•  multiplicity 

In  order  to  reference  sets  of  objects  from  the  associated  classes,  each  connection,  c,  in  class 
A  defines  a  sort  in  A  that  is  unified  with  the  class  set  sort  of  the  associated  class.  The  formal 
transformation  of  a  connection  to  a  sort  in  an  association  is  defined  in  Rule  OMT-45. 

c  €  A.Connection  =>•  c.Name-CLASS  6  A-Sori  (OMT-45) 

In  order  to  constrain  the  multiplicity  of  the  objects  based  the  number  of  links  in  the  as¬ 
sociation,  there  must  be  a  way  to  determine  the  number  of  links  a  given  object  participates  in. 
As  defined  in  Section  6.4.1,  this  corresponds  to  the  image  operation.  Assuming  the  association  is 
a  simple  (no  qualifier)  binary  association,  the  signature  for  the  two  image  operations  defined  by 
components,  Ci  and  C2,  is  shown  below. 

IMAGE  :  A.Name,ci.Name  c2.Name-CLASS 
IMAGE  :  A.Name, C2.Name  —*  ci.Name-CLASS 

Both  operations  take  an  association  object  (a  set  of  links)  and  an  object  from  one  of  the  two 
associated  classes  and  returns  the  set  of  objects  that  are  associated  with  the  input  object  by  links 
in  the  association.  Assuming  two  classes  ci  and  C2  are  in  a  simple  binary  association  Assoc,  the 
image  operation  is  defined  as  follows. 

V(S  :  Assoc, X  :  ci.Name,y  :  C2.Name) 

Z  €  5  A  attr-name{ci){l)  =  x  A  attr-name{c2){l)  =  y) 

O-  2/  e  image{S,x) 
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The  formal  translations  are  defined  below 


Cl,  C2  €  A.Connection  A  unde finedP.{c\. Qualifier)  A  unde finedl{c2. Qualifier) 

A  {IMAGE,  [A.7Vame,  ci.JVame],  [c^-Name-CLASS])  6  ^Operation 
{IMAGE,  [A.Name,  C2.Nam^,  [c\.Name-CLASS\)  G  AOperation 
A  ‘y{ASSOC  :  AName)  {X  G  ci.Name  AY  G  ca-Name 
A  LINK  G  ASSOC  A  attr-name{ci){LINK)  =  X 
A  attr-name{c2){LI N K)  =  Y) 

<^Y  G  IMAGE{ASSOC,  X)AXg  IMAGE{ASS0C,  F)”  £  AAxiom  (OMT-46) 

In  order  to  reference  objects  from  the  associated  classes,  each  connection,  c,  in  class  A  defines 
a  sort  in  Al  that  is  unified  with  the  class  sort  of  the  associated  class.  The  formal  transformation 
of  a  connection  to  a  sort  in  an  association  is  defined  in  Rule  OMT-47. 

c  G  A.Connection  =>  c.Name  G  Assort  (OMT-47) 

A  connection  qualifier  is  used  to  discriminate  between  links  in  an  association.  According 
to  Section  6.4.2,  a  qualifier  becomes  an  attribute  of  the  link  class.  This  requirement  is  specified 
formally  in  Rule  OMT-48. 

Ci,C2  G  A.Connection  A  definedl{c\. Qualifier)  =P- 

{ci.Qualifier.Name,[c2.Name],[type{ci.Qualifier)])  G  A^. Attribute  (OMT-48) 

This  qualified  attribute  is  used  to  define  a  different  image  operation  in  the  association  spec¬ 
ification.  In  this  image  operation,  the  qualifier  is  used  as  an  additional  parameter.  Assuming 
component  ci  had  a  qualifier  attached  to  it  (which  becomes  an  attribute  of  component  C2  by 
Rule  OMT-48),  the  following  image  operation  would  be  generated. 

IMAGE  :  A.Name, Cl. Name,type{ci. Qualifier)  -+  C2.Name-CLASS 

This  image  operation  is  defined  formally  below. 
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ci,C2  €  A.Connection  Adefined?{ci.Qualifier)  Aundefined'!{c2.Qualifier)  => 

A  {IMAGE,  [MName,  ci.Name,type{ci.Qualifier)],  [c2.Name-CLASS\)  €  KOperation 
{IMAGE,  [MName,  C2. Name],  [ci.Name-CLASS])  €  ^.Operation 
A  “'^{ASSOC  :  AName){X  €  ci.Name  AY  €  C2.NameA  Z  e  type{ci.Qualifier) 

(A  LINK  €  ASSOC  A  attr-name{ci){LI N K)  =  N 
A  attr-name{c2){LINK)  —  Y)  Ac\.Qualifier.Name{LINK)  =  Z 
<^Y  e  IMAGE{ASSOC,  X,Z)  AX  e  IMAGE{ASSOC,  Y)”  e  A.  Axiom  (OMT-49) 

The  multiplicity  of  a  component  defines  how  many  of  each  component  may  be  referred  to  by 
links  in  the  association  class  A  and  thus  generates  multiplicity  axioms  over  the  image  operations 
defined  above.  These  multiplicity  axioms  are  very  similar  to  the  aggregate  multiplicity  axioms 
defined  in  Section  7.2.1.  According  to  the  Theory-Based  Object  Model,  for  binary  associations 
there  are  five  types  of  multiplicities:  one,  many,  optional,  plus,  or  numerically  specified.  The 
axioms  generated  by  these  multiplicities  for  simple  binary  associations  are  shown  below. 


One 

Many 

Plus 

Optional 

Specified 

Specified 


SIZE{IMAGE{A,0))  =  1 
SIZE{IMAGE{A,0))  >  0 
SIZE{IMAGE{A,0))  >  c.Plus. integer 
SIZE{IMAGE{A,  O))  =  0V  SIZE{IMAGE(A,  O))  =  1 
SIZE{IMAGE{A,0))  =  c.Specif  ied.  Spec- Range,  valuel 
SI  Z  E{I  M  AGE{A,0))  >  c.Specif  ied. Spec-Range.valuel 
A  SIZE{IMAGE{A,0))  <  c.Specif  ied. Spec-Range.value2 


The  formal  association  multiplicity  transformations  for  simple  associations  are  defined  below. 
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c  e  A.Connection  A  undefinedl{c.Qualifier)  A  c.Mult  =  One 
“X  6  c.Name  ^  SIZE{IMAGE{A,X))  =  1”  €  Pl Axiom 


(OMT-50) 


c  g  A.Connection  A  undefined?(c.Qualifier)  A  c.Mult  =  Many 

^  “X  e  c-Xame  =>  SIZE{IMAGE{A,X))  >  0”  €  A. Axiom  (OMT-51) 

c  6  A.Connection  A  undefined? (c.Qualifier)  A  c.Mult  =  PZus  => 

“X  €  c.Xame  =>  SIZE{IMAGE{A,X))  >  c. Plus. integer"  e  A. Axiom  (OMT-52) 

c  G  A.Connection  A  undefined?  {c.Qualifier)  A  c.Mult  =  Optional 
“X  €  c.Name 

^  {SIZE(IMAGE(A,  X))  =  0  V  SIZE{IMAGE{A,  X))  =  1)”  £  A. Axiom  (OMT-53) 

c  G  A.Connection  A  undefined?  {c.Qualifier)  A  c.Mult  =  Specified  => 

OiZ({ox  I  s  G  c.Mult  A 

(de fined? {s. valued)  =>  ax  =  “X  G  c.Name  {SIZE{IM AGE(A,  X))  >  s.valuel 

A  SIZE{IMAGE{A,X))  <  s.value2)”) 

A  {undefined? {s.value2) 

^  oa:  =  “X  G  c.Xame  =>  SIZE{IMAGE{A,X))  =  s.valuel")}) 

g  XAxiom  (OMT-54) 

The  formal  association  multiplicity  transformations  for  qualified  associations  are  defined  below. 
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c  €  A.Connection  A  defined?{c.Qualifier)  A  c.Mult  =  One 

=^>  “V  {X  ;  c.Name,Z  :  type{c.Qualifier))  SIZE(IMAGE{A,X,Z))  =  1” 

6  A-Axiom  (OMT-55) 


c  e  A.Connection  A  defined?{c.Qualifier)  A  c.Mult  —  Many 

^  “V  (X  :  c.Name,  Z  :  type{c.Qualifier))  SIZE(IMAGE{A,X,  Z))  >  0” 

£  A.Axiom  (OMT-56) 


c  £  A.Connection  A  defined?(c.Qualifier)  A  c.Mult  =  Pius  ^ 

“V  (X  :  c.Name,  Z  :  type{c.Qualifier)) 

SIZE{IMAGE{A,X,  Z))  >  c.Plus. integer”  £  A.Aa:iom  (OMT-57) 

c  £  A.Connection  A  de fined? (c.Qualifier)  A  c.Mult  =  Optional 
“V  (X  ;  c.Name,  Z  :  type{c.Qualifier)) 

SIZE{IMAGE(A,X,Z))  =  0  V  SIZE{IMAGE{A,X,  Z))  =  1”  £  A. Axiom  (OMT-58) 

c  £  A.Connection  A  de fined? (c.Qualifier)  A  c.Mult  =  Specified  => 

“V  (X  ;  c.Name,  Z  :  type{c.Qualifier))”  ||  OP({ax  |  s  £  c.Mult 
A  {de fined? (s.valuei)  =>  ax  = 

“SIZE{IMAGE{A,X,Z))  >  s.valuelA  SIZE{IMAGE{A,X,Z))  <  s.valueT) 

A  {unde fined?{s. valued)  ax  = 

‘^SIZE{IMAGE{A,  X,  Z))  =  s.valuel”)})  £  A.  Axiom  (OMT-59) 


where  OR  is  a  function  that  returns  the  logical  disjunction  of  all  axioms  in  the  input  set. 

Section  6.4  requires  each  association  to  define  a  new  event  to  create  a  new  association.  There 
is  no  create  method  in  an  association  since  an  association  has  no  attributes.  Because  the  class  sort 
of  an  association  is  a  set,  the  new  event  returns  an  empty  set.  This  requirement  is  captured  by 
defining  a  new  event 

NEW-AName  :  — >  AName 

with  the  axiom  defining  a  new  class  set  to  be  empty. 

NEW-AName{)  =  EMPTY-SET 

Formally,  these  definitions  are  captured  by  the  following  transformation  rule. 
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A  g  0-Slang-DomainTheory 

{NEW-A.Name,  Q,  [A-ATarwe])  6  A.Event 

A  “NEW-A.Name{)  =  EMPTY-SET"  e  A. Axiom  (OMT-60) 

7. 2.4.1  Link  Classes.  A  link  class,  Al,  defines  an  object  with  object  valued  at¬ 
tributes  referencing  each  object  in  a  given  link.  A  link  may  also  contain  additional  attributes, 
operations,  methods,  and  events.  The  formal  transformation  for  each  item  in  A  is  defined  below. 

Connections.  Because  an  association  relates  two  or  more  classes,  A  must  have 
at  least  two  connections.  These  connections  define  which  classes  belong  to  the  association.  A 
connection  consists  of  the  following  items: 

•  name 

•  qualifier  (with  a  name  and  a  datatype) 

•  role 

•  multiplicity 

The  multiplicity  of  a  component  defines  axioms  in  the  association  class  A  and  are  not  used 
in  the  link  class  definition.  To  reference  objects  from  the  associated  classes,  each  connection,  c,  in 
class  A  defines  an  object  valued  attribute  in  Al  that  takes  the  class  sort  of  Al  as  input  and  returns 
the  reference  to  an  object  from  class  c.Name.  This  attribute  declaration  is  generally  of  the  form: 

c.Name-OBJ  :  At. Name  — ►  c.Name 

However,  if  the  user  has  defined  a  role  name  for  the  connection,  the  role  name  is  used  as  the 
attribute  name  as  shown  below. 

c.role  :  Al  .Name  c.Name 

Using  the  attr-name  function  defined  in  Equation  7.1,  the  formal  transformation  of  a  connec¬ 
tion  to  an  object  valued  attribute  in  a  link  is  defined  in  Rule  OMT-61. 

a  e  A.Connection  ^  {attr-name{a),  [A.Name-LINK],  [a])  6  At. Attribute)  (OMT-61) 
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Attributes.  Additional  link  attributes  may  be  entered  directly  into  the  object 
model  and  are  transformed  exactly  like  class  attributes  as  defined  in  Rules  OMT-13  and  OMT-14 
except  that  C  A  and  C  Al- 

Operations.  User-defined  link  operations  may  also  be  entered  directly  into  the 
object  model.  These  operations  are  transformed  exactly  like  class  operations  as  defined  in  Section 
7.5  (Rules  OMT-89  -  OMT-91)  except  that  C  A  and  C  i-» 

Create  Method/New  Event.  The  only  method  created  automatically  for  a  link 
is  the  create  method  similar  to  the  create  method  defined  for  classes  in  Rule  OMT-16.  However, 
to  create  a  link,  all  object  references  must  be  provided  to  the  create  method.  Therefore,  the  link 
create  method  has  the  signature 

C  RE  AT  E-linkname  ;  componenti,  ...,componentn  — ►  linkname 

while  the  new  event  has  a  similar  signature. 

N EW -linkname  :  componenti,  ...,componentn  — ►  linkname 

Then,  for  each  component  in  the  link,  an  axiom  of  the  form 

componenti{C  RE  AT  E-linkname{xi, ...,  Xn))  =  Xi 

is  added  to  the  axiom  block  of  the  link  class,  while  the  axiom  causing  the  new  event  to  invoke  the 
create  method 

ATTR-EQU AL{NEW-A.Name{xi...Xn),  CREATE-A.Name{xi...Xn) 

is  also  generated  and  placed  in  the  link  class  attribute  block.  The  formal  definition  of  the  link  create 
operation  and  new  event  is  shown  below,  followed  by  the  definition  for  the  attr-equal  operation. 
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A  6  GOMT-DomainTheory  =>■ 

{CREATE-C.Name,  link-domain,  [A.Name])  €  M. -Method 

A  {NEW-C. Name, link-domain,  [A.Name])  hL-Event  (OMT-62) 


A  e  GOMT-DomainTheory  => 

“ATTR-EQUAL{CREATE-C.Name{link-domain),  CREATE-C.Name{link-domain))” 

€  Axiom  (OMT-63) 


A  6  GOMT-DomainTheory  => 

{ATT R-EQUAL,[A-Name,  A.Name],  [Boolean]}  e  A^. Operation 

A  “ATTR-EQUAL{0i,02)  =  link-compare{A)”  £  A^. Axiom  (OMT-64) 


where  link-domain  is  defined  as  the  sequence  of  parameters 

link-domain(c)  =  [d  |  c  6  A.Connection 

A  (defined?(c.role)  =J>  d  =  c.role)  (7.16) 

A  (unde fined? (c.role)  =>  d  =  c.name)] 

and  link-compare  is  defined  as  the  pairwise  comparison  of  all  link  attributes  and  component  at¬ 
tributes  of  Al  as  shown  below. 


link-compare(C)  =  AND({''‘'a(Oi)  =  oc(02)”  \  ct  £  C.NormAttr}  (7  17) 

U  {“attr-name(c)(Oi)  =  attr-name(c){02)”  \  c  £  C. Connection})  ^  '  ' 

The  axiom  that  defines  a  link  create  method  is  simple  since  object  references  for  each  com¬ 
ponent  must  be  provided.  This  axiom  takes  the  form 

attr-name(xi)(CREATE-A.Name{xi,...Xn))  =  x, 

where  Xi  represents  a  parameter  in  the  parameter  string  of  create  and  attr-name(xi)  is  the  object 
valued  attribute  name  in  the  link  class  corresponding  to  that  component.  Formally,  the  creation  of 
the  set  of  axioms  is  given  by  Rule  OMT-65. 


c  €  A.Connection  A  index (cr eate-domain{C),  z)  =  index(A.Connection,  c.Name) 

=>  “c.Name(CREATE-C.Name(link-create-domain(C)))  =  z"  £  C.Axiom  (OMT-65) 


The  function  index  is  the  index  of  a  symbol  within  a  sequence  (the  domain-ident  of  the  event)  and 
the  function  link-create-domain  is  defined  as 
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create-domain{a)  =  [unique{x.Name)  \  x  £  a.Connection] 


(7.18) 


and  unique  is  a  function  that  returns  a  unique  symbol  name  based  on  the  input  symbol. 

7.5  Dynamic  Model  Translations 

The  dynamic  model  of  a  GOMT  Class  C  defines  the  dynamic  behavior  of  a  class  in  the  form 
of  a  statechart.  The  dynamic  model  defines  the  allowable  states  that  an  object  may  be  in  and  its 
behavior  while  in  that  state.  Objects  transition  from  one  state  to  the  next  based  on  the  receipt 
of  events  from  external  objects.  After  receiving  an  event,  an  object  may  react  by  changing  state, 
invoking  a  method,  or  sending  additional  events.  The  dynamic  model  consists  of  the  following 
items  in  the  GOMT  AST. 

•  set  of  states 

•  set  of  transitions 

The  dynamic  model  may  or  may  not  exist  for  a  given  class.  The  transformations  defined  in  the 
dynamic  model  are  assumed  to  occur  after  C  is  converted  to  an  0-Slang  specification,  C,  based 
on  the  object  model.  The  transformations  for  states  and  transitions  are  defined  below. 

7.3.1  States.  Each  state  in  C  has  three  possible  attributes: 

•  name 

•  invariant  axioms 

•  set  of  substates 

If  the  dynamic  model  is  defined  in  a  class  C  then  four  types  of  declarations  are  added  to  C.  However, 
before  adding  these  declarations,  the  set  of  states  must  be  partitioned  into  n  partitions  such  that 
1)  there  is  exactly  one  initial  state  in  each  partition,  2)  each  state  is  reachable  from  the  start  state, 
and  3)  there  are  no  transitions  between  partitions.  If  n  >  2  then  there  are  n  distinct  concurrent 
subdiagrams  for  class  C. 

1.  First,  for  each  partition  i  G  l...n,  a  sort  declaration  as  shown  below  is  created. 
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C.Name-STATE-i 


2.  Second  a  state  attribute  of  the  form 

C.Name-STATE-i :  C.Name  C.Name-STATE-i 

is  created  for  each  partition  i  G  l...n. 

3.  Then,  each  state  in  partition  i  €  l...n,  a  generates  a  nullary  operation  (constant)  in  the  states 
block  of  C  of  the  form 

O'. Name  C.Name-STATE-i 

4.  Finally,  for  each  pair  of  states  in  partition  i  G  l...n,  <y\  and  0-2,  the  axiom 

ffi.Name  ^  a^.Name 

is  added  to  the  axioms  of  C. 

Each  state,  a,  may  also  contain  substates.  If  a  state  contains  substates  then  four  additional 
declarations,  similar  to  the  ones  defined  above,  are  generated  for  state  a.  Again  however,  before  the 
declarations  can  be  added,  the  concurrent  state  partitions  for  the  subdiagram  must  be  computed. 
To  determine  these  concurrent  partitions,  the  set  of  substates  of  cr  is  separated  into  n  partitions 
such  that  1)  there  is  exactly  one  initial  state  each  each  partition,  2)  each  state  is  reachable  from 
the  start  state,  and  3)  there  are  no  transitions  between  partitions.  Again,  n  >  2  indicates  that 
there  are  n  distinct  concurrent  substate  diagrams  for  state  a. 

1.  First,  for  each  partition  i  G  l...n,  a  sort  declaration  as  shown  below  is  created. 

a.Name-SUBSTATE-i 

2.  Second,  for  each  partition  i  G  l...n,  a  state  attribute  of  the  form 

cr.Name-SUBSTATE-i  :  C.Name  a.Name-SUBSTATE-i 

is  created. 

3.  Then,  each  state  ip,  in  each  partition  i  G  l...n  of  state  <7,  generates  a  nullary  operation 
(constant)  in  the  states  block  of  C. 

Ip. Name  cr.Name-SUBSTATE-i 
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4.  Finally,  for  each  pair  of  states  in  partition  i  G  l...n,  and  ^>2,  the  axiom 

ipi.Name  ^  •^•i.Name 

is  added  to  the  axioms  of  C. 

Formal  definition  of  these  transformations  starts  with  the  computation  of  the  set  of  concurrent 
state  partitions.  For  a  given  state,  s,  its  partition  of  concurrent  state  sets,  is  given  by  the 
following  recursive  definition. 

base{s)  =  {{si,S2)  |  (t,  81,82)  t  e  C. Transition  A  (a  =  si\/ s  =  82)  At.  fromstate  =  si 

Ar-fromstate  /  Initial- State- Marker  A  r.ToState  =  82)  /"v  1  o'! 

V  ((si,Sm)  €  6ase  A  (sm,S2)  €  6ase)}  '  ' 

TTs  =  {s  I  {s,  8m)  &  base  W  {8m,s)  e  base} 

Then  the  set  of  all  partitions,  lie,  is  defined  as  below.  Since  He  is  defined  as  a  set,  there  is  only 
one  partition,  ttc  for  each  partition  of  concurrent  states  in  C.  (11  is  also  computable  on  states  that 
have  substates.) 

He  =  {ttj  I  8  €  C. State}  (7.20) 

Once  the  partitioning  of  states  is  complete,  the  four  0-Slang  declarations  described  above 
are  defined.  The  first  transformations  create  declarations  for  a  sort  and  state  attribute  for  each 
partition  as  shown  in  Rule  OMT-66  and  OMT-67. 

i  G  He  =>  C.Name-ST ATE-i  G  C.Sort  (OMT-66) 

i  G  He  =>  {C.Name-ST ATE-i,  [C.JVome],  \C.Name-ST ATE-i])  G  C.StateAttr  (OMT-67) 

The  third  transformation  creates  a  nullaxy  operation  declaration  for  each  state  in  the  partition 
as  shown  in  Rule  OMT-68. 

*  G  He  =>  (s  G  TTj  =>  (s.Name,  [],  [C.Name-ST ATE-i])  G  C.State)  (OMT-68) 

And  finally,  to  ensure  each  state  created  by  Rule  OMT-68  is  unique.  Rule  OMT-69  defines 
the  appropriate  state  uniqueness  axioms. 
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i  e  He  A  Si,  S2  G  TTi  A  Si  /  S2  =^-  “si  /  S2”  G  C. Axiom 


(OMT-69) 


Once  a  class’s  base  states  are  defined,  the  substates,  as  discussed  above,  can  be  translated. 
Therefore,  for  any  given  superstate,  a,  with  as  defined  in  Equation  7.20,  the  following  rules 
translate  the  substates  of  cr. 

a  G  states{C)  A  (3  (s)  s  G  a. State)  => 
i  G  n<T  => 

a.Name-SUBSTATE-i  G  C.Sort  (OMT-70) 

A  {cr.Name-SUBSTATE-i,[C.Name],[a.Name-SUBSTATE-i])  G  C.StateAttr  (OMT-71) 
A  s  G  TTi  =>  (s.Name,  Q,  [a-.Name-SUBSTATE-i])  G  C.State  (OMT-72) 

A  Si,  S2  G  TTj  A  Si  S2  =>  “si  ^  S2”  G  C. Axiom  (OMT-73) 

where  states  is  the  set  of  all  states  of  C  as  defined  below. 

states{C)  =  {s  |  s  G  C.State  V  (s  G  si. State  A  si  G  states{C))}  (7.21) 

7.3.2  Transitions.  In  the  dynamic  model,  transitions  are  used  to  represent  incoming 
events  and  actions  taken  by  the  object.  Transitions  translate  into  events,  methods,  axioms,  and 
event  theories  in  the  0-Slang  AST  and  consist  of  six  components. 

•  name 

•  set  of  parameters  (name  and  datatype) 

•  set  of  guard  conditions  defined  via  axioms 

•  set  of  actions 

•  from-state 

•  to-state 

As  defined  in  Section  6.2.3,  actions  are  used  to  specify  methods  or  events  sent  to  other  objects. 
In  the  GOMT  AST,  actions  are  decomposed  into  three  components. 

•  name 

•  sequence  of  parameters  (each  with  a  name  and  datatype) 
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•  set  of  actions 


If  the  action  name  is  SEND  the  object  is  to  send  the  parameterized  event  specified  by  the  sub¬ 
action.  This  is  the  only  valid  use  of  sub-actions.  If  the  action  name  is  not  SEND  then  the  action 
defines  a  method  in  C.  Therefore,  a  transition  defines  a  receive  event  along  with  possibly  multiple 
methods  and  send  events.  The  relationship  between  these  events  and  methods  are  defined  by  a 
transition  axiom. 

Each  transition,  r,  in  class  C  defines  an  incoming  event  signature  in  the  event  block  of  C. 
Each  parameter,  p,  in  r.parameter  becomes  a  parameter  in  the  event  as  defined  below. 

T.Name  :  C.Name,pi...p„  — »  C.Name 

The  translation  into  the  0-Slang  AST  is 

T  €  C.Transition  ^  {r-Name,  [C.Name]  ||  domainir),  [C.Name])  6  C.Event  (OMT-74) 
where  domain  is  defined  as  in  Equation  7.4. 

Each  non-SEND  action,  s,  in  r  defines  a  signature  in  the  method  block  of  C  and  each  param¬ 
eter,  p,  in  s. parameter  becomes  a  parameter  of  the  method  as  shown  below. 

s.Name  :  C.Name,p\...pn  — *  C.Name 

This  transformation  is  captured  formally  in  Rule  OMT-75. 

r  e  C.Transition  A  s  €  r. Action  A  r.Name  ^  SEND 

^  {s.Name,  [C.Name]  ||  domain{s.Parameter),  [C.Name])  e  C.Method  (OMT-75) 

Each  subaction,  s,  in  r  defines  an  outgoing  event  in  C  as  well  as  an  event  theory  specification 
that  is  used  later  in  an  aggregate  specification  to  unify  C  with  the  receiving  object’s  class  speci¬ 
fication.  The  event  theory  defines  an  event  sort  and  signature  and  is  imported  into  C;  therefore, 
instead  of  creating  a  signature  for  the  outgoing  event,  the  event  theory  name  (which  is  the  event 
name,  s.Name)  is  added  to  the  import  block  of  C.  An  event  theory  is  shown  below 
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event  s. Action. Name  is 

class-sort  s. Action. Name- SORT 
sorts  pi,...,pn 

events  s.Action.Name  :  s.Action.Name-SORT,pl...pn  — >  s. Action. Name- SORT 
end-event 


where  pi...pn  denote  the  parameters  of  the  outgoing  event.  Formally,  this  transformation  is 


T  6  C.Transition  A  s  €  r. Action  A  s.Name  =  SEND 

=>  Ce  e  O-Slang-DomainTheory  (OMT-76) 

A  Ct..Name  =  s.Action.Name  (OMT-77) 

A  Cg.. Classsort. Class-Sort-Id  =  s.Action.Name-SORT  (OMT-78) 

A  (s.Action.Name,  [s.Action.Name-SORT]  ||  domain(s.Action.Parameter), 

[s.Action.Name-SORT])  €  Cg. Event  (OMT-79) 

A  s.Action.Name  6  C.Import  (OMT-80) 


where  domain  is  again  defined  in  Equation  7.4. 

Before  sending  an  event,  the  sending  object  must  know  where  to  send  it.  Section  6.6  requires 
each  event  have  an  object- valued  attribute  of  the  form 

s.Name-OBJ  :  C.Name  s.Name-SORT 

to  define  where  an  event  is  sent.  This  declaration  is  generated  and  placed  in  the  attribute  block  of 
C.  Formally,  this  translation  is  shown  in  Rule  OMT-81  (the  sort  s.Name-SORT  is  defined  in  the 
imported  event  theory  in  Rule  OMT-78  above). 

T  e  C.Transition  As  €  t. Action  A  s.Name  =  SEND 

=>  (s. Action. Name-OBJ,  [C.Name],  [s.Action.Name-SORT])  £  C.Attribute  (OMT-81) 

Each  transition  defines  an  axiom  that  causes  the  object,  upon  receipt  of  an  incoming  event  in 
the  appropriate  state,  to  state  change  as  well  as  invoke  methods  and  send  events.  This  axiom  has 
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five  parts:  current  state,  guard  condition,  new  state,  method  invocations,  and  sending  of  events. 
These  parts  are  merged  into  a  single  axiom  of  the  form: 

old-state  A  guard-condition  =>•  new-state  A  method-invocations  A  event-sends 

Using  functions  to  define  the  individual  aspects  of  the  axiom  (i.e.,  old-state,  guard-condition,  new- 
state,  method-invocations,  and  event-sends),  Rule  OMT-82  defines  the  axiom  for  each  event  except 
the  initial  new  event. 

r  S  C. Transition  A  T.FromState  ^  Initial-State-Marker 

=>  “old-state(T.FromState)  A  guard-condition{T)  ^  new-state^r) 

A  method-invocationslr)  A  event-sends{T)”  6  C.Axiom  (OMT-82) 

r  e  C.Transition  A  T.FromState  =  Initial- State-Marker  =>•  “new-state{T) 

A  method-invocations{T)  A  event- sends{T)”  6  C.  Axiom  (OMT-83) 

The  functions  old-state,  guard-condition,  new-state,  method-invocations  and  event-sends  are 
defined  below. 

Old-State  Because  the  from-state  is  a  mandatory  part  of  a  transition,  an  old-state  is  always 
generated.  If  the  t. from-state  is  a  top-level  state  then  the  old-state  part  of  the  axiom  is 
simply 

C.Name-STATE{o)  =  t. from-state 

However,  if  the  from-state  is  a  substate  of  another  state  then  the  superstate  must  be  in  the 
correct  state  as  well,  as  shown  below. 

C.Name-STATE{o)  =  super state{T,  from-state) 

A  superstate{T,from-state)-SUBSTATE{o)  =  r. from-state 

In  this  example,  superstate  is  a  function  that  determines  the  superstate  of  a  substate.  Obvi¬ 
ously,  there  can  be  many  levels  of  substates  so  that  an  arbitrary  number  of  superstates  may 
be  included  in  the  old  state  part  of  the  axiom. 
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Formally,  the  definition  of  the  old-state  function  is  shown  in  Rule  7.22.  The  definition  of 
old-state  is  recursive  and  relies  on  the  partitioning  of  states  defined  above  in  Equation  7.19. 


(3  (s,  si)  s  6  states{C)  t\<r  —  si.Name  A  si  €  s. State)  ha 

=>  old-state{a)  —  “old-state{s)  A  s.Name-SUBSTATE-i{C.Name)  —  a” 
{s  e  statesiC)  =>  a  =  si. Name  A  si  ^  s.State)  ha 
=»  old-state{a)  =  C .N ame-ST AT E{C .N ame)  =  a" 

where  states  is  defined  in  Equation  7.21  above. 


Guard-Condition  The  guard  condition  part  of  the  transition  axiom  is  optional.  If  the  guard 
condition  does  exists,  it  is  assumed  that  the  guard  condition  is  an  axiom  written  in  0-Slang 
syntax  based  on  the  object’s  attribute  values  and  incoming  parameter  values  only.  Thus  if 
the  guard  condition  exists,  it  requires  no  translation. 


defined?{T.  Axiom)  =>  guard-condition{T)  =  t.  Axiom 
unde fined?(T. Axiom)  =>  guard-condition(T)  =  “true” 


(7.23) 


New-State  Because  a  transition  always  has  a  to-state,  the  new  state  part  of  the  transition  axiom 
is  defined  by  T.to-state  and  takes  the  form 

C.Name-STATE{T.Name{o,pi...pn))  =  r.tostate 

or,  if  the  state  is  a  substate, 

superstate{T,tostate)-SUBSTATE{r.Name{o,p-L...pn))  =  r.tostate 


where  pi—Pn  denote  the  parameters  of  the  incoming  event.  If  the  transition  occurs  in  a 
substate  diagram,  the  values  of  superstate  attributes  do  not  change.  Formally,  the  definition 
of  new-state  is 


(3  (s,  si)  8  G  3tates{C)  A  r.ToState  =  si.Name  A  si  G  s.State)  A  r.ToState  G  TTj 

=>  new-stateij)  =  “s.Name-SUBSTATE-i{T.Name{C.Name,domain{T))  =  r.ToState” 
{s  G  states{C)  ^  r.ToState  =  si.Name  A  si  ^  s.State)  A  r.ToState  G  tt; 

=>  new-state{T)  =  C.Name-ST ATE(C.Name,domain{T))  =  r.ToState” 

(7.24) 


where  domain  is  defined  in  Equation  7.4. 
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Method-Invocations  A  non-SEND  action,  a,  specifies  that  a  method  is  invoked  as  the  result  of 
the  event  receipt.  As  defined  in  the  Section  6.2.5,  the  form  used  to  specify  method  invocation 
is 

attr-equal{T.Name(o,pi...pn),T.Action.Name{o,pai...pa2)) 

where  pi . .  .pn  denote  the  parameters  of  the  incoming  event  and  pai--  ■Pa2  denote  the  parameters 
of  the  method.  The  formal  definition  of  the  method-invocations  function  is  shown  below. 

method-invocations(T)  =  AND{{inv  \  s  €  t. Action  A  s.Name  /  SEND 

A  inv  =  “ATTR-EQUAL{T.Name(C.Name,domain(T)),  (7.25) 
s.Name(C.NaTne, domain{s)))”}  U  {“true”}) 

The  AND  function  in  Equation  7.25  denotes  the  logical  conjunction  of  all  axioms  in  the  input 
set.  The  true  axiom  ensures  that  there  is  at  least  one  axiom  returned  from  method-invocations 
thus  ensuring  that  Rule  OMT-82  is  well  formed. 

Event-Sends  SEND  actions  represent  the  sending  of  a  subaction  event  to  the  object  whose  ref¬ 
erence  is  stored  in  the  appropriate  object-valued  attribute.  Therefore,  a  SEND  action  with 
sub-action,  s,  generates  the  axiom 

s.Name-OBJ(r.Name{o,pi...pn))  =  a.Name{s.Name-OBJ{o),psi...ps2) 

where  pi-.-Pn  denote  the  parameters  of  the  incoming  event  and  Pai---Pa2  denote  the  parameters 

of  the  outgoing  event.  Event-Sends  is  formally  defined  in  Equation  7.26. 

event-sends{T)  =  AND{{snd  \  s  €  r.Action  A  s.Name  —  SEND 

A  snd  =  “s.Action.Name-OBJ{T.Name{C.Name,domain[r)))  =  , 

s.Action.Name{s.Action.Name-OBJ{X),domain{s. Action)))”}  ^  '  ' 

U  {“true”}) 

Once  the  valid  transitions  have  been  transformed  and  all  incoming  events  and  states  defined 
in  C,  invalid  transitions  can  be  computed.  Because  the  theory-based  object  model  assumes  there 
is  no  reaction  to  an  event  that  occurs  in  a  state  with  no  explicitly  defined  transition  for  that  event, 
axioms  explicitly  stating  this  assumption  must  be  generated.  These  axioms  are  of  the  form 

old-state  =>•  same-state 

which  is  formally  generated  by  Rule  OMT-84. 
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s  £  C.  State  A  e  £  C.  Event 


A  -i(3  (t)  r  £  C. Transition  A  r.Name  =  e.Name  A  r.FromState  =  s.Name) 

^  "'old-stateia)  =>■  saTne-state{e,  s)”  £  C. Axiom  (OMT-84) 


where  old-state  is  defined  as  before  in  Equation  7.22  and  same-state  is  defined  below  in  Equa¬ 
tion  7.27. 


(3  (s,  si)  s  £  states{C)  Acr  =  si.Name  A  si  £  s. State)  A  cr  £  TTj 

=>  aame-state{e,a)  =  “s.Name-SUBSTATE-i{e.Name{event-domain{e))  —  cr" 
{s  £  statea{C)  a  —  si.Name  A  si  ^  a. State)  A  c  £  TTi 

=>  aame-atate{e,  a)  =  C.Name-STATE(event-domain{e))  =  a” 

and  event-domain  is  defined  as 

event-domain(e)  =  [unique{x)  \  x  £  e.Domain-Ident] 

and  unique  is  a  function  that  returns  a  unique  symbol  name. 


't-i  Functional  Model  Translation 

The  OMT  functional  model  is  depicted  as  a  basic  dataflow  diagram  and  defines  a  set  of 
processes  and  the  dataflow  between  them.  In  the  GOMT  AST,  a  class  C  functional  model  consists 
of  the  following  components. 

•  set  of  processes  (with  subprocesses) 

•  set  of  dataflows 

•  set  of  datastores 

The  functional  model  may  or  may  not  exist  in  a  given  class.  If  it  does,  it  is  assumed  that  the 
following  transformations  are  performed  after  C  is  converted  to  an  0-Slang  specification,  C,  based 
on  the  object  model.  The  translation  of  each  of  the  above  components  is  discussed  below. 

7.4-1  Processes.  As  defined  in  the  GOMT  AST,  processes  have  the  following  components. 

•  name 

•  set  of  input  data  flows  (name  and  datatype) 

•  set  of  output  data  flows  (name  and  datatype) 
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•  set  of  subprocesses 


As  interpretted  by  the  theory-based  object  model,  processes  define  purely  functional  methods 
or  operations  that  take  data  of  the  type  defined  by  the  input  datafiows  and  produce  data  of  the 
type  of  defined  by  the  output  data  flows  as  defined  in  Section  5.5.  If  the  output  dataflow,  o,  of  a 
process,  p,  or  any  of  its  subprocesses,  is  to  a  datastore,  then  the  process  modifies  the  object,  or 
subobjects,  of  which  it  is  a  part  and  defines  a  method.  If  a  dataflow  is  to/from  a  datastore,  the 
name  of  the  object- valued  attribute  referencing  the  datastore  becomes  the  parameter  name  (i.e., 
the  datastore  is  input  to  the  method)  instead  of  the  dataflow  datatype.  If  any  subprocesses  of  p 
have  dataflows  that  are  input  from  datastores,  those  datastores  must  be  also  be  part  of  the  method 
input  parameters.  A  method  signature  for  a  process  p  is  defined  as 

p.Name  :  C.Name,  flowtype(ii)...flowtype{i„)  -*  C.Name 

where  are  the  input  dataflows  and  flowtype  is  a  function  that  returns  the  datastore  object¬ 

valued  attribute  or  dataflow  type  depending  on  whether  the  dataflow  is  from  a  datastore.  Formally, 
the  transformation  of  processes  that  represent  methods  is  defined  in  Rule  OMT-85. 

(p  G  processes{C)  A  size{datastores-niodified{C,p))  >  1 

=>  {p.Name,  [C.Name]  ||  dataflow-domain{p),  [C.Name])  S  C.Method) 

A  {p  £  processes(C)  A  size{datastores-modified{C,p))  =  1 
=>  {p.Name,  [datastore-sort{C,p)]  ||  dataflow-domain{p), 

[datastore-sort{C,p)])  £  C.Method)  (OMT-85) 

where  processes  is  defined  in  Equation  7.6  and  the  function  datastores-modified  defines  the  set  of 
all  datastores  modified  by  a  process  and  is  defined  as 

p  G  processes(C) 

datastores-modified(C,p)  (7.28) 

=  {d  I  d  £  C. Datastore  A  f  £  d.InFlows  Ao  £  all-out  f  lows  (p)  A  /  =  o} 

where  all-outflows  is  a  function  that  produces  the  set  of  all  output  dataflows  from  p  or  any  of  its 
subprocesses 
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all-out f  low s{p)  =  {/I/  e  p.OutFlows}  U  {all-out f  low €  processes{p)} 


(7.29) 


and  dataflow- domain  is  a  function  that  returns  the  sequence  of  input  dataflow  types  as  define  below. 

dataflow-domain{p)  =  [flowtype{f)  \  f  e  p.InFlows]  (7.30) 


The  function  flowtype  used  in  Equation  7.30  returns  the  datastore  name  or  the  dataflow  type  as 
defined  below. 


(d  e  C. Datastore  A  /i  6  d.InFlows  A  /i  =  /  =>•  flowtype{f)  =  d.Name) 

A  ((-i3  (d,  /,  /i)  d  €  C. Datastore  A  /i  €  d.InFlows  A  fi  =  f)  =>  , 

{de fined?  {f .type)  =>  flowtype(f)  =  f.type  '  ' 

A  unde  fined?  {f  .type)  ^  type{f)  =  f.Name)) 

The  function  datastores-sort  returns  either  the  class  sort  of  C,  the  name  of  the  datastore  accessed 
by  p,  or  an  empty  string  if  no  datastores  are  accessed  as  defined  below. 


{size{datastores-modified{C,p))  =  1  Ad  €  datastores-modified(C,p) 

=>  datastore-sort{C,p)  =  d.Name) 

A  (size{datastores-modified{C,p))  >  1 
=>  datastore- sort{C,p)  =  C.Name) 

A  (size(datastores-modified{C,p))  =  0 
{size{datastores-accessed{C,p))  >1 
datastore-sort(C ,p)  =  C.Name) 

A  {size{datastores-accessed{C,p))  =  1  A  d  S  datastores-accessed{C,p) 

=>  datastore- sort{C,p)  =  d.Name) 

A  {size{datastores-accessed{C,p))  =  0  ^  datastore-sort{C,p)  =“”)) 

where  datastores-accessed  is  a  function  that  returns  all  datastores  accessed  by  a  process  and  is 
defined  as 


p  e  processes{C)  => 

datastores-accessed{C,p)  (7.33) 

=  {d  I  d  €  C. Datastore  A  /  6  d.OutFlows  Ao  £  all-inflows{p)  A  f  =  o} 

where  the  function  all-inflows  is  defined  in  Equation  7.34. 


all-inflows{jp)  =  {f\f  €  p.InFlows  V  (/  €  all-inflow s{pi)  Ap\  £  processes{p))}  (7.34) 


If  there  are  no  output  dataflows  from  process  p  or  its  subprocesses  that  are  sent  to  datastores, 
then  process  p  defines  an  operation  signature.  Again,  if  any  input  dataflows  of  any  subprocesses 
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of  p  is  from  a  datastore,  that  datastore  must  also  be  included  in  the  operation  input  parameters. 
If  there  are  multiple  subprocess  dataflow  that  access  datastores,  then  the  format  of  the  operation 
signature  is  shown  below. 

p.Name  :  C.Name,type{i\)...type{in)  — ►  ox.type...Om-type 

If  there  is  only  one  subprocess  dataflow,  Oaub  that  accesses  a  datastore  then  the  following  operation 
signature  is  used. 

p.Name  :  datasore-sort{C,p),type{ii)...type{in)  — >  ox.type...Om.type. 

where  datastore- sort  is  defined  in  Equation  7.32  and  oi.type...Om-type  are  the  output  dataflow 
datatypes.  The  formal  transformation  is  shown  below. 

p  G  processesifi)  A  size{datastores-Tnodified{C,p))  =  0 

(p.Name,[datastore-sort{C,p)\  ||  data flow-domain{p),[C. Name]) 

€  C.Operation  (OMT-86) 

If  a  process  has  subprocesses,  then  those  subprocesses  and  their  associated  dataflows  define 
the  composition  of  the  process.  This  composition  is  defined  axiomatically  for  each  process,  p,  with 
subprocesses  the  following  axiom  is  created. 

p.Name{proc-domain{p))  =  proc-range{p)  A  implementing-axioms{p) 

where  proc-domain(p)  and  proc-range(p)  are  functions  defining  domain  and  range  variables  while 
implementmg-axioms(p)  is  a  function  that  creates  a  sub-axiom  for  each  subprocess,  pi,  of  p  as 
shown  below. 

proc-range{pl)  =  p.Name{proc-domain{p)) 

The  functions  proc- domain (p)  and  proc-range(p)  generate  signatures  that  are  compatible  with 
the  operation  and  method  signatures  defined  above;  however,  they  insert  variable  names  instead  of 
datatypes  according  to  the  following  rules. 
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{size{datastores-modified{C,p))  >  0  proc-domain{p)  =  C. Name,  ii. Name. ..in-Name) 

A  (size{datastores-modified{C,p))  =  0  ^ 

{size{datastores-accessed{C,p))  >  1  =>  proc-domain{p)  =  C. Name, ii.Name... in-Name) 
A  {size{datastores-accessed{C,p))  =  1 

proc-domain(p)  =  datasore-sort{C,p),  ii.Name. ..in-Name)) 


(7.35) 


where  is  the  set  of  all  input  flow  names  in  p.InFlows. 

{size(datastores-modified(C,p))  =  1  proc-range{p)  =  datastore-sort{C,p)) 

A  {size{dataatores-modified{C,p))  >  0  proc-range{p)  =  C.Name)  (7.36) 

A  {size[dataatores-modified{C,p))  =  0  proc-range{p)  =  oi.Name.-.On.Name) 

where  oi...o„  is  the  set  of  all  input  flow  names  in  p.OutFlows. 

Therefore,  The  formal  transformation  of  the  axiomatic  definition  of  a  process  p  with  subpro¬ 
cesses  is 


p  €  proceaaea{C)  A  de fined? (p.Proceaa) 

‘^p.Name{proc-domain(C,p))  =  proc-range{C,p)  A  implementing-axioms{p)” 

e  C.Axiom  (OMT-87) 


where  implementing- axioma  is  defined  as 


implementing-axioma{p)  =  AND({“proc-range(pi)  =  pi.Name{proc-domain{pi))'" 

I  pi  €  processes  (p)} 


(7.37) 


where  AND  denotes  the  logical  conjunction  of  all  input  axioms. 


7-4-2  Dataflows.  Dataflows  are  not  translated  directly  into  components  of  an  O-Slang 
specification.  They  are  used  in  defining  the  method/operation  signature  and  subprocess  axioms  for 
GOMT  processes.  Dataflows  correspond  to  the  inputs  and  outputs  of  methods  and  operations. 

7-4-3  Datastores.  Datastores  are  not  translated  directly  into  components  of  an  0-Slang 
specification.  They  are  used  in  defining  the  method/operation  signature  and  subprocess  axioms 
for  GOMT  processes.  Datastores  represent  object  classes  and  associations  within  an  aggregate 
specification  and  are  accessed  via  object- valued  attributes  referencing  those  classes  and  associations. 
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7.5  Additional  Translations 

Additional  information  may  supplied  as  part  of  the  GOMT  Class,  C.  In  this  research  this 
additional  information  consists  of  the  following  items: 

•  set  of  axiomatic  constraints 

•  set  of  operation  definitions 

Each  of  these  items  may  or  may  not  exist  in  a  given  class.  These  transformations  are  performed 
after  C  is  converted  to  an  0-Slang  specification,  C,  based  on  the  object  model,  functional  model, 
and  dynamic  model. 

7.5.1  Constraints.  Constraints  are  user  supplied  0-Slang  axioms  that  constrain  the 
behavior  of  various  components  of  the  class.  Therefore,  each  constraint  in  C  is  translated  directly 
to  axioms  in  the  axiom  block  of  C  as  shown  below. 

c  €  C. Axiom  c  €  C.Axiom  (OMT-88) 

7.5.2  Operations.  Operations  in  the  GOMT  AST  can  represent  three  different  0-Slang 
constructs:  1)  a  newly  defined  0-Slang  method,  2)  a  newly  defined  O-Slang  operation,  or  3)  the 
method  definition  of  an  action  in  the  dynamic  model.  A  GOMT  Operation  consists  of  the  following 
items. 

•  name 

•  set  of  parameters  (with  a  name  and  datatype) 

•  result 

•  definition 

•  boolean  denoting  whether  it  is  abstract 

An  operation  result  is  its  output  datatype.  If  the  operation  has  no  defined  result,  the  operation 
is  a  method  and  the  output  datatype  is  the  class  sort  of  C.  Each  GOMT  operation,  o,  defines  a 
signature.  If  the  result  is  the  class  sort  of  C  or  result  is  not  defined,  then  the  operation  defines  a 
method  signature,  as  shown  below,  which  is  added  to  the  method  block  of  C. 
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o.Name  :  C.Naine,pi...pn  —>■  C.Name 

where  pi...pn  are  parameter  datatypes  from  the  parameter  set  of  o.  The  formal  definition  of  these 
translations  is  given  in  Rule  OMT-89  below. 

o  6  C.GOMT-Op  A  (undefined? (o.Result)  V  o. Result  =  C.Name) 

=>  (o.Name,  [C.Name]  ||  domain(o),  [C.Name])  6  C.Method  (OMT-89) 

where  domain  is  defined  in  Equation  7.4. 

If  the  result  of  o  is  a  datatype  other  than  the  class  sort  of  C  then  o  defines  an  operation  whose 
signature  is  placed  in  the  operations  block  of  C. 

o.Name  :  C.Name, pi...p„  — >  o.result 

This  translation  is  shown  formally  in  Rule  OMT-90. 

o  €  C.GOMT-Op  A  defined?(o. Result)  A  o. Result  ^  C.Name 

^  (o.Name,  [C.Name]  ||  domain(o),[o. Result])  6  C.Operation  (OMT-90) 

The  definition  of  an  operation,  o,  is  a  set  of  user  supplied  axioms  in  0-Slang  syntax.  It  is 
assumed  that  the  axioms  are  syntactically  valid  and  correctly  define  the  operation.  The  axioms  in 
the  definition  of  o  translate  directly  into  axioms  in  the  axiom  block  of  C  as  shown  below. 

c  €  C.GOMT-Op. Definition  =>  c  &  C.Axiom  (OMT-91) 

7.5.3  Imports.  The  specification  import  statements  are  used  to  include  external  spec¬ 
ifications  in  the  definition  of  the  current  specification.  These  imported  specifications  may  either 
be  aggregate  specifications,  superclass  specifications,  or  specifications  defining  the  sorts  used  for 
attributes,  parameters,  qualifiers,  or  operation  results.  The  following  rule  defines  exactly  which 
specifications  must  be  included  in  a  class  specification. 
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C  €  0-Slang-DomainTheory  => 

CJmport  =  C.Import  U  {class-imports{C)  \  imports{C))  (OMT-92) 


where  class-imports  is  a  function  that  collects  the  references  to  all  external  specifications  within 
C.  The  function  imports  determines  which  specifications  are  already  imported  into  C  through 
specifications  already  in  ’C.Import  by  Rules  OMT-3,  OMT-7,  OMT-20,  and  OMT-80.  Therefore, 
the  set  difference  between  class-imports (C)  and  imports(C)  is  a  set  of  specification  names  that 
must  be  included  in  C.Import.  The  definition  of  class-imports  and  imports  are  given  below  in 
Equations  7.38  and  7.8. 

class-imports(c)  —  {a  |  s  €  c.Operation.Domain  —  Ident 
II  c.Operation.Range-Ident 
II  c.Attribute.Range-Ident 

II  c.Method.Domain-Ident  (7.38) 

II  c.Method.Range-Ident 
II  c.  Event.  Domain- 1  dent 
II  c.Event.Range-Ident} 


7. 6  Translation  Correctness 

In  this  section,  I  show  that  the  translation  of  the  object,  functional,  and  dynamic  models  as 
defined  in  Section  7.2,  Section  7.3,  and  Section  7.4  are  correct  with  respect  to  the  formal  semantics 
defined  in  Chapter  V.  I  prove  this  by  showing  that  the  diagram  in  Figure  7.1  composes.  That  is 
that  for  each  OMT  model,  the  mapping  defined  by  the  formal  semantics,  ip,  is  equivalent  to  the 
composition  of  the  translation  of  the  GOMT  model  to  0-Slang  by  r  followed  by  the  mapping 
from  0-Slang  to  the  formal  semantics,  lo  as  defined  in  Equation  7.39. 


V(T>  :  GOMT-DomainTheory)  ’p{D)  =  u!{t{D))  (7.39) 


A  second  useful  property  to  prove  about  r  would  be  to  show  that  the  inverse  transformation 
T~^,  results  in  a  domain  theory  equivalent  to  the  original  (i.e.  D  =  t~^{t{D))).  While  this  would 
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Figure  7.1  OMT  Translation  Composition 


not  help  prove  correctness,  it  would  show  the  bijective  nature  of  r  as  well  as  its  completeness. 
Unfortunately,  the  early  design  decision  to  have  only  a  single  axiom  block  per  0-Slang  specification 
eliminates  this  possibility.  Because  a  user  may  enter  free-form  axioms  to  define  operations  and 
class  constraints,  the  ability  to  determine  where  0-Slang  axioms  were  generated  (i.e.,  manually 
or  automatically  from  the  functional  or  dynamic  model)  is  impaired.  A  fairly  simple  modification 
to  the  0-Slang  syntax  and  AST  (along  with  the  associated  transformations)  could  solve  this 
problem  allowing  r  to  be  bijective.  However,  due  to  time  constraints,  these  modifications  were  not 
implemented  in  this  research. 

7. 6. 1  Object  Model  Correctness.  In  this  section,  I  show  that  the  translation  of  the  GOMT 
object  model  as  defined  in  Section  7.2  is  correct  with  respect  to  the  object  model  semantics  defined 
in  Section  5.3.3.  I  start  by  defining  a  mapping  (p  from  the  GOMT  object  model  to  the  formal 
semantics  of  the  restricted  OMT  object  model  as  defined  in  Section  5.3. 

Given  the  formal  semantics  defined  in  Section  5.3,  an  object  model  O  consists  of  a  set  of 
specifications,  S  where  a  specification  may  consist  of  five  items: 

1.  Name.  The  name  of  S'  -  a  single  symbol. 
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2.  Imports.  The  imports  of  S  are  a  set  of  specification  names. 


3.  Sorts.  The  sorts  of  S  are  a  set  of  symbols. 

4.  Operations.  Operations  of  S  are  defined  as  a  tuple,  {name,  domain,  range),  where  domain 
and  range  are  a  sequence  of  sorts. 

5.  Axioms.  The  axioms  are  a  set  of  first-order  logical  statements  defined  over  the  sorts  and 
operations  defined  in  S,  or  in  the  specifications  imported  by  S.  I  assume  all  axioms  are  in 
0-Slang  syntax. 

For  the  definition  of  (fi,  r,  and  u,  I  assume  that  only  the  object  model  is  defined  and  that 
no  methods  or  operations  are  defined  manually  by  the  user.  I  also  assume  that  all  associations 
are  binary  and  that  there  are  no  qualified  associations  or  aggregates.  The  binary  association 
assumption  is  made  to  simplify  the  mappings  and  proofs  although  the  results  can  be  extended  to 
include  higher-order  association  as  well.  Qualified  associations  and  aggregations  are  not  included 
since  they  were  not  included  in  the  object  model  semantics  as  defined  by  Bourdeau  and  Cheng  (14) 
and,  while  interesting,  add  little  to  the  semantics.  Finally,  I  assume  that  all  attributes  are  defined 
with  explicit  datatypes.  While  not  necessary,  it  simplifies  the  mapping  definitions  and  the  proof. 


Definition  7.6.1  v?.  The  mapping  g)  from  the  object  model  of  a  class,  C,  in  a  GOMT  domain 
theory  to  an  object  model,  OM,  is  defined  in  Equations  7.40  through  7.55.  In  these  equations  the 
function  comp-pred  (Equation  7.56)  defines  the  the  predicate  name  by  returning  either  H  AS  -PART 
or  c.Role  depending  on  whether  c.Role  is  defined  and  mult-subaxiom  (Equation  7.57)  defines  the 
sub-axioms  of  each  range  in  a  Specified  multiplicity. 


C  6  GOMT-DomainTheory.GOMT-Class  A  C.Name  =  n 
So  €  OM  A  Sc-Name  =  n  A  n  &  Sc-Sorts 


(7.40) 


a  €  C. Attribute  ^ 

{a. Name,  [C.Name],  [a.datatype])  6  Sc  .Operations  A  a.datatype  6  Sc -Imports 


(7.41) 


c  6  C.Connection  ■<=>■  {comp-pred{c),  [C.Name,  C.Name],  [Boolean])  6  Sc -Operations  (7.42) 
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c  e  C.Connection  A  c.Mult  =  One 

“X  g  c.Name  =>  SIZE{{Y  \  comp-pred(c){X,Y)})  =  1”  G  Sc ■  Axioms) 
c  e  C.Connection  A  c.Mult  =  Many 

“X  G  c.Xame  =>  5/^i;({Y  |  comp-pred(c)(X,y)})  >  0”  G  Sc. Axioms)  ' 

c  G  C.Connection  A  c.Mult  =  Plus 

“X  G  c.Name  =J-  SIZE{{Y  \  comp-pred{c){X,Y)})  >  c.Plus. integer"  G  Sc  .Axioms)' 
c  G  C.Connection  A  c.Mult  —  Optional 

“X  G  c.Xome  ^  (5/ZE({y  |  comp-pred{c){X,  Y)})  0  ( 

V  SIZE{{Y  I  comp-pre(i(c)(X,y)})  =  1)”  G  Sc  -  Axioms) 

c  G  C.Connection  A  c.Mult  =  Specified  A  sori  =  c.Name  A  pred  =  comp-pred{c) 

A  s  G  c.Mult  A  vi  =  s.valuel  A  vi  =  s.value2 

{ax  €  Sc  .Axioms  A  mult-8uhaxiom{sort,pred,vi,V2)  C.  ax  . 

A  ax  —  OR{{mult-subaxiom{sort,pred,  xi, X2)  \  c  G  C.Connection  ' 

A  c.Mult  =  Specified  A  sort  =  c.Name  A  pred  =  comp-pred{c) 

A  a  G  c.Mult  A  vi  =  s.valuel  A  V2  =  s.value2 

c  G  C. Superclass  {simulates,  [C.Name],  [c])  G  Sc -Operations  A  c  G  Sc-Imports  ( 

>1.  G  GOMT-DomainTheory. Assoc  A  A.Name  =  n  <=>  , 

5a  €  OM  A  SA-Name  =  n  A  n  G  SA-Sorts  ^ 

dom  =  [c.Name  |  c  G  A.Connection]  , 

({C.Xame,  dom,  [BooZean])  G  5A-Opero<ions  A  c  E.  dom  c  e  SA-Imports)  ' 

c  G  A.Connection  A  c.Mult  =  One  , 

“X  G  c.Name  ^  SIZE{{Y  \  SA.Name{X,Y)})  =  1”  G  SA-Axioms  ^ 

c  G  A.Connection  A  c.Mult  =  Many  . 

“X  G  c.Name  =(►  5J2’B({y  1  SA.Name{X,  Y)})  >  0”  G  SA-Axioms  ^ 

c  G  A.Connection  A  c.Mult  =  Plus  •<=>  , 

“X  G  c.Name  =>•  5/2'B({Y  |  SA.Name{X,Y)})  >  c.Plus. integer"  G  SA-Axioms 

c  G  A.Connection  A  c.Mult  =  Optional  ^ 

“X  G  c.Name  ^  {SIZE{{Y  ]  SA.Name{X,  Y)})  =  0  ( 

V  SIZE{{Y  I  SA.Name{X,Y)})  =  1)”  G  SA-Axioms 

c  G  C.Connection  A  c.Mult  =  Specified  A  sort  =  c.Name  A  pred  =  C.Name 
A  s  G  c.Mult  A  vi  =  s.valuel  A  V2  =  s.value2 
{ax  E  Sc -Axioms  A  mult-subaxiom{sort,predvi,V2)  C  ax 

A  ax  =  OR{{mult-3ubaxiom{sort,pred,xi,X2)  \  c  G  C.Connection  ^ 

A  c.Mult  =  Specified  A  sort  =  c.Name  A  pred  =  C.Name 
A  s  E  c.Mult  A  vi  =  s.valuel  A  V2  =  s.value2 


defined! {c.Role)  =>  comp-pred{c)  =  c.Role 

unde  fined?  {c.  Role)  comp-pred{c)  =  HAS-PART 

mult-subaxiom{sort,  pred,  vi,V2)  =  ax 

A  {defined?{v2)  ^  ax  =  “X  G  sort  =>  {SIZE{{Y  \  pred{X,Y)})  >  vi 
A  SIZE{{T  \  pred{X,Y)})  <  V2)") 

A  {undefined?{v2)  ax  =  “X  G  sort  ^  {SIZE{{Y  |  pred(X,  Y)})  =  vi)”) 
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Definition  7.6.2  w.  The  mapping  u  from  an  O-Slang  class,  C,  to  an  object  model,  OM' ,  is 
defined  in  Equations  7.58  through  7.74.  In  these  equations  the  function  om-pred  (Equation  7.75) 
converts  the  component  attribute  name  in  0-Slang  to  the  appropriate  predicate  name  in  OM  and 
the  function  sort-of  (Equation  7.76)  finds  the  class  sort  of  the  class  referenced  by  an  object-valued 
attribute. 


C  6  0-Slang-DomainTheory. Class  A  C.Name  =  n  O- 
Sc  €  OM'  A  Sc-Name  =  n  A  n  €  Sc-Sorts 


(7.58) 


a  €  C. Attribute  A  a.Range-Ident(l)  ^  x-CLASS  A  a.Range-Ident{l)  ^  x- ASSOC  ^ 
a  €  Sc -Operations  A  a.Range-Ident{l)  £  Sc  .Imports 


(7.59) 


a  £  C.Operation  A  a.Range-Ident  =  [C.Name]  A  a. Name  ^  ATT R-EQU AL  <=>• 
a  £  Sc -Operations  A  (i  £  a.Range-Ident  i  £  Sc -Imports) 


(7.60) 


c  6  C.attribute  A  c.Range-Ident  =  [name-CLASS\  ■<=> 

(om-pred{c.Name),[<C,.Name,name\,[Boolean\)  £  So  .Operations 

“SIZE{name{X))  =  1”  €  C.Axiom 

“X  £  sort-of  (name)  =>  SIZE{{Y  \  om-pred(name){X,Y)})  =  1”  6  Sc  -Axioms) 
“SIZE{name{X))  >  0”  £  C.Axiom 

“X  £  sort-of  (name)  SIZE{{Y  |  om-pred{name){X,Y)})  >  0”  £  Sc  .Axioms) 

“SIZE{name(X))  >  x”  £  C.Axiom  A  a;  ^  0 

“X  £  sort-of  (name)  SIZE{{Y  \  om-pred{name){X,Y)})  >  x”  £  Sc  -Axioms) 

‘'SIZE(name{X))  =  1  V  SIZE(name{X))  =  0”  €  C.Axiom  ^ 

“X  £  sort-of  (name)  “(SIZE{{Y  \  om-pred{name){X,Y)})  =  0 
V  SIZE{{Y  I  om-pred(name){X,Y)})  =  1)”  £  Sc  -Axioms) 

a  £  A.  Axioms 

A  (“{SIZE(name{X))  >n  A  SIZE(name{X))  <  m)”  C  a 
V  {“SIZE{name{X))  =  n”  C  a  A  n  >  1)) 

<=>  (ax  £  S A- Axioms 

A  ((“(SIZE(name(X))  >  n  A  SI ZE(name(X))  <  m)”  C  a) 

■O’  (“X  £  sort-of  (name)  O-  (SIZE({Y  |  om-pred(name)(X,Y)})  >  n 
A  SIZE({Y  I  om-pred(name)(X,Y)})  <  m)’’  C  ax)) 

A  (“SIZE(name(X))  =  n”  C  a) 

•O  “X  £  sort-of  (name) 

O-  (SIZE({Y  I  om-pred(name)(X,Y)}))  =  n”  C  ax))  £  SA-Axioms 

c  6  C.Clas3-Sort.Inherited-Sort-Id 

•O  (simulates,  [C.A^ame],  [c])  €  Sc -Operations  A  c  £  Sc  -Imports 


(7.61) 

(7.62) 

(7.63) 

(7.64) 

(7.65) 


(7.66) 


(7.67) 


A  £  0-Slang-DomainTheory. Association  A  AName  =  n-e^ 

Sa  €  OM  A  SA-Name  =  n  A  n  £  SA-Sorts 

dom  —  [a.Domain-Ident(2)  \  a  £  AOperation  A  a.Name  =  IMAGE]  •O 

((C.Name,  dom,  [Boolean])  €  SA-Operations  A  c£  dom  =>  c  £  SA-Imports) 

“X  e  sort  O  SIZE(IMAGE(A,X))  =  1”  €  A  Axioms  -O 

“X  €  sort  O  SIZE({Y  ]  SA.Name(X,Y)})  =  1”  G  SA-Axioms 


(7.68) 

(7.69) 

(7.70) 
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“X  e  sort  SIZE{IMAGE(A,X))  >  0”  €  A. Axioms  ^ 

“X  €  sort  SIZE{{Y  \  SA-Name{X,Y)})  >  0”  €  SA-Axioms 

“X  e  sort  SIZE{IMAGE{A,X))  >  x”  €  A  Axioms  ^ 

“X  €  sort  =>  SIZE{{Y  \  SA-Name{X,Y)})  >  x”  €  SA-Axioms 


(7.71) 

(7.72) 


“X  €  sort  =>  (SIZE(IMAGE(A,X))  =  0  V  SIZE{IMAGE(A,X))  =  1)”  6  A  Axioms  ^ 

“X  €  sort  {SIZE{{Y  \  SA-Name{X,  y)})  =  0  (7.73) 

V  SIZE{{Y  I  S^.Arame(X,y)})  =  1)”  £  SA-Axioms 

a  6  AAxioms 

A  C‘XesortA{SIZE{IMAGE{A,X))>nASIZE{IMAGE{A,X))<m)"  C  a 
V  (“X  £  sort  A  SIZE{IMAGE(A,X))  =  n”  C  o  A  n  >  1)) 

(ax  £  SA-Axioms 

A  ((“X  £  sort  A  (SIZE{IMAGE{A,X))  >  n  A  SIZE{IMAGE{A,X))  <  m)”  C  a)  (7.74) 
44-  (“X  £  sort  A  (SIZE{{Y  |  SA.Name{X,Y)})  >  n 

A  SIZE{{Y  I  SA.NameiX,Y)})  <  m)”  C  ax)) 

A  (“X  £  sort  A  {SIZE{IMAGE{A,X))  =  n”  C  a) 

•O  “X  £  sort  A  (SIZE{{Y  |  SA-Name{X,Y)}))  =  n”  C  ax))  £  SA-Axioms 


The  function  om-pred  is  defined  in  Equation  7.75  below.  Basically,  if  the  component  attribute 
name  has  a  -OBJ  ending,  there  was  no  role  name  assigned  to  the  component  and  thus  the  default 
HAS-PART  pvedic&te  name  is  used.  If  the  attribute  name  does  not  have  an  -OBJ  ending,  then  the 
attribute  name  is  the  role  name  and  no  transformation  is  made. 


c  =  component-0 BJ  om-pred{c)  =  HAS-PART 

c  /  component-OBJ  om-pred(c)  —  c  (7.75) 


The  function  sort-o/ finds  the  class  sort  of  the  class  referenced  by  an  object- valued  attribute 
since  by  OMT-5,  aggregate  components  in  a  GOMT  class  generate  object-valued  attributes  that 
are  named  either  by  the  class  name  or  role.  The  definition  of  sort-of  is  given  in  Equation  7.76. 


a  £  C.Attribute  A  a. Name  =  c  A  [so7’t-CL.45'5]  =  a.Range-Ident  =>  sort-of  (c)  =  sort  (7.76) 


7.6.2  Object  Model  Correctness  Theorem.  In  this  section,  Theorem  VII.l  establishes  the 
correctness  of  the  object  model  translation  with  respect  to  the  object  model  semantics  established 
in  Section  5.3.3. 
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Theorem  VII.l  Given  a  valid  GOMT  domain  theory  class  G  with  a  well  defined  object  model,  the 
translation  to  0-Slang  as  defined  by  r  in  Section  7.2  preserves  the  semantics  of  the  object  model 
as  defined  in  Definition  5.3.1. 

Proof.  See  Appendix  F 

7.6.3  Dynamic  Model  Gorrectness.  In  this  section,  I  show  that  the  translation  of  the 
GOMT  dynamic  model  as  defined  in  Section  7.3  is  correct  with  respect  to  the  dynamic  model 
semantics  defined  in  Section  5.4.  I  start  by  defining  a  mapping  tp  from  the  GOMT  dynamic  model 
to  the  formal  semantics  of  the  restricted  OMT  dynamic  model. 

For  the  definition  of  ip,  r,  and  ui,  I  assume  that  substates  and  concurrent  states  have  already 
been  translated  into  this  simple  automata  as  discussed  in  Section  5.4.4.  With  this  assumption,  (p 
is  defined  eis 


Definition  7.6.3  (p.  The  mapping  (p  from  the  dynamic  model  of  a  class,  C,  in  a  GOMT  domain 
theory  to  a  statechart,  M  =  ((3,S,  A,  5,  A,  go)  defined  as 


Q  =  {s.Name  |  s  €  C. State} 

S  =  {t.Name  \  t  E  C.Transition} 


A  =  {msig{t. Action)  [  t  E  C.Transition  A  t. Action. Name  ^  SEND} 

U  {esig{t. Action. Action)  \  t  E  C.Transition  A  t. Action. Name  =  SEND} 


S{q,a) 


t.ToState  i/  3  (t  E  C.Transition)  such  that  t.FromState  =  q 
A  t.Name  =  a  A  t.  Axiom  holds 
q  otherwise 


X{q,a)  =  { 


^  sig{t. Action) 

io 


i/  3  (t  E  C.Transition)  such  that  defined1{t. Action) 
A  t.Name  =  cr  A  t. Axiom  holds 
A  A  t.FromState  =  q 
otherwise 


qo  =  Initial-State 
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where  the  function  msig  defines  the  functional  signature  of  a  method  action  as  defined  in  Equa¬ 
tion  7.77. 


msig{a)  =  {a.Name,[C.Nara^  ||  domain{a. Parameter),  [C.A^ame])  (7.77) 


The  function  esig  defines  the  functional  signature  of  an  event  send  action  as  defined  in  Equation  7.78. 


esig{a)  =  {a.Name,  [a.Name-SORT]  ||  domain{a. Parameter),  [a.Name-SORT])  (7.78) 


The  function  sig  defines  the  signature  of  each  method  or  event  send  action  as  defined  in  Equa¬ 
tion  7.78. 


sig{a)  =  {s  |  t  e  a  A  unde finedt^t.  Action)  =>■  s  =  msig{t) 

A  defined7{t. Action)  ^  s  =  esig{t. Action)}  (7.79) 


Definition  7.6.4  w.  The  mapping  w  from  an  0-Slang  class,  C,  to  a  statechart,  M'  — 
{Q',Ti',A',S',X',qQ)  is  defined  as 


Q'  =  {s.Name  \  s  €  C.State}  U  {Initial-State-Marker} 

S'  =  {e.Name  \  e  €  C.Event} 

A'  =  {m  I  m  €  C.Method  A  e  e  <C.Event  A  a  G  C.Axiom 

Aa  =  “C.Name-STATE{x)  =  q...  =»  C.Name-STATE{a{...))  =  q^  ...” 
A  “ATTR-EQU AL{e.Name{...),m.Name{...))”  n  o} 

U  {e  I  e.Name  G  C.Import  A  Qe  G  0-Slang-DomainTheory 
A  CE-Name  =  e.Name  A  e  G  <Ce -Event} 
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q2  if  ax  €  C.Axiom 

A  ax  =  “C.Name-STATE(x)  =  q  A  guard 
^  C.Name-STATE{a{..))  =  q2  ...” 

A  guard  holds 

92  if  Q  =  Initial-State-Marker  Aax  e  C.Axiom 

A  ax  =  “C.Name-STATE{NEW-C.Namei...))  =  52  •••” 
A  guard  holds 
q  otherwise 


X'{q,a) 


(  action-set{ax) 


action-set{ax) 

.  {} 


if  ax  €  C.Axiom 

A  ax  —  ^^C.Name-STATE{x)  =  q 
A  guard  ^  C.Name-ST ATE{a{...))  =  q2  ...” 

A  guard  holds 

if  q  =  Initial-State-Marker  Aax  G  C.Axiom 

A  ax  =  “C.Name-STATE{NEW-C.Name{...))  =  q2  ...” 
A  guard  holds 
otherwise 


qg  —  Initial-State 


where  C  is  the  boolean-valued  subsequence  operator  and  ...  matches  zero  or  more  characters  in 
axiom. 


action-set{a)  =  {m  \  me  C.Method  A  “ATTR-EQUAL{cr{...),m.Name{...))”  C  0} 

U  {e  I  e.Name  e  C.Import  ACe  e  0-Slang-DomainTheory 
A  Qe  .Name  =  e.Name  A  e  £  Qe  .Event} 

^‘'e.Name-OBJ {a {...))  =  e.Name{e.Name-OBJ{x)...)”  c  a}  (7.80) 


7.6.4  Dynamic  Model  Correctness  Theorem.  In  this  section,  Theorem  VII.2  establishes 
the  correctness  of  the  dynamic  model  translation  with  respect  to  the  dynamic  model  semantics 
established  in  Section  5.4.4. 


Theorem  VII.2  Given  a  valid  GOMT  domain  theory  class  C  with  a  defined  dynamic  model,  the 
translation  to  0-Slang  as  defined  by  r  in  Section  7.3  preserves  the  semantics  of  the  dynamic  model 
as  defined  in  Definition  5.4.2. 

Proof.  See  Appendix  F 
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1.G.5  Functional  Model  Correctness.  In  this  section,  I  show  that  the  translation  of  the 
GOMT  functional  model,  as  defined  in  Section  7.4,  is  correct  with  respect  to  the  functional  model 
semantics  defined  in  Section  5.5.4.  I  start  by  defining  a  mapping  ip  from  the  GOMT  functional 
model  to  the  formal  semantics  of  the  restricted  OMT  functional  model. 

For  the  definition  of  ip,  r,  and  w,  I  assume  that  all  methods  and  operations  are  defined  either 
as  1)  actions  from  the  GOMT  dynamic  model,  or  2)  processes  from  the  OMT  functional  model. 
Furthermore,  I  assume  that  all  actions  defined  in  the  dynamic  model  have  a  process  definition  in  the 
functional  model  and  that  derived  attributes  (which  result  in  operations)  are  not  defined.  While 
these  assumptions  are  not  critical  to  the  result  of  the  proof,  it  eliminates  clutter  caused  by  the 
definition  of  “default”  functional  models  for  methods  and  operations  without  explicit  functional 
models.  These  assumptions  imply  that  the  required  object  “create”  process  is  included  as  part  of 
the  functional  model  and  is  not  created  automatically  by  the  default  rule  OMT-16. 

Definition  7.6.5  ip.  The  mapping  ip  from  the  functional  model  of  a  class,  C,  in  a  GOMT  domain 
theory  to  a  dataflow  diagram,  D  =  (C,  F,  K,  R)  is  defined  as 

C  =  {c.Name  \  c  ^  {proc{C)UC.DataStoreiJ  {Extern})} 

F  =  dfmerge{C.DataFlow) 

K  =  {c.Name  \  c  €  (proc(C)  U  C.DataStore)} 

R  =  {{x,y)  I  (x,  y  G  dfmergeiC.DataFlow)  A  x.Target  =  y. Source  A  x. Tar  get  ^  Extern) 

V  {{x,z)^R/\{z,y)€R)} 

where  the  function  proc  defines  the  set  of  all  processes  and  subprocesses  within  the  class  C  as  defined 
below. 


proc{c)  =  {p  I  p  e  c.Process  V  (pi  G  proc{c)  Ape  pi. Process)}  (7.81) 
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and  the  function  dfmerge  modifies  all  subprocess  dataflows  where  it  appears  in  the  subdiagram 
that  the  source  or  target  of  the  dataflow  is  external,  when  in  fact  the  source  or  target  is  a  process 
from  a  higher  level  diagram.  In  the  functional  model  of  Figure  7.2  the  output  c  from  process  P14 
defines  a  dataflow  with  an  external  target;  however,  in  actuality,  P14  produces  output  c  for  the 
higher-level  process  PI  whose  target  is  process  P3.  The  function  dfmerge  is  defined  below. 


Figure  7.2  Dataflow  Definitions 

di  £  d  A  di. Target  ^  Extern  A  di. Source  ^  Extern  di  G  dfmerge{d) 

di  €  d  A  di.Target  =  Extern  A  ->(3  (d2)  d2  £  d  A  {di.Name,  di.Type)  =  {d^.Name,  d2.Type) 

A  d2. Tar  get  /  Extern)  =?►  di  £  dfmerge{d) 

di  £  d  A  di. Source  =  Extern  A  ->(3  (d2)  d2  £  d  A  {di.Name,  di.Type)  =  {d2.Name,  d2.Type) 

A  d2. Source  /  Extern)  =>  di  £  dfmerge{d) 

di,  d2  £  d  A  {di.Name,  di.Type)  =  {d2.Name,d2.Type)  A  di. Source  =  Extern  A  d2. Source  ^  Extern 
=>  {di. Name,  di. Type,  d2. Source,  di.Target)  £  dfmerge{d) 
di,d2  £  d  A  {di.Name,  di.Type)  =  {d2.Name,d2.Type)  A  di.Target  =  Extern  A  d2.Target  ^  Extern 
=>  {di. Name,  di. Type,  di. Source,  d2.Target)  £  dfmerge{d)  (7.82) 

Definition  7.6.6  w.  The  mapping  u>  from  an  0-Slang  class,  C,  to  a  dataflow  diagram,  D'  = 
{C',F',K',R')  is  defined  as 


7-55 


C'  =  {c.Name  \  c  £  C.Method  V  c.Name  €  datastores{C) 

V  (c  S  C.Operation  A  c.Name  ^  IMAGE  A  c.Name  /  ATTR-EQU AL)} 
U  {Satern} 

F'  =  dfmerge{{f  \  f  e  dataflows-of(a)  A  a  €  CAxiom.}) 

K'  =  C'\  {Extern} 

R' =  {{x,y)  I  {x,y  £  dfmerge{{f  \  a  €  C.Axiom  A  f  €  dataflows-of{a)}) 

A  x.Target  =  y. Source  A  x.Target  ^  Extern) 

V  ((x,  z)  eR'  A  {z,  y)  e  iZ')} 


datastores{c)  =  {d  \  ax  £  c.Axiom 

A  (ax  =  “m(x, ...)  =  xi  A  ...d(xi)  =  m2{d{x), 

y  ax  =  “m{d{x), ...)  —  d{xi)  A  ...d{xi)  =  m2{d{x), 
y  ax  =  “m{d{x), ...)  —  ...  A  ...  —  o{d{x), (7.83) 

The  function  dataflows- of  Aefi.Tii.es  the  seven  valid  mappings  from  0-Slang  functional  axioms 
generated  by  Rule  OMT-87  as  shown  in  Table  7.1.  In  the  comment  region  of  Table  7.1,  illegal 
means  that  a  dataflow  from  the  listed  source  to  the  listed  target  is  illegal  in  standard  dataflow 
diagrams.  The  comment  constrained  means  that  the  particular  combination  of  source  and  target 
are  illegal  by  restriction  of  the  functional  model  as  described  in  Section  5.5.3. 


dataflows-of{a)  = 

[a  ^  “m{i\...im)  =  oi...o„...  A  ri...r„  =  sp(di...d„)...”  dataflows-of{a)  =  {} 
a  =  “m{ii...im)  =  oi...On...  A  r\...rn  —  sp{di...dn)...”  ^  dataflows- of  {a)  = 

{x  I  t  €  top-level{a)  A  opi,op2  €  operations{a) 

A  Pi  £  opi.dom  Ap2  £  op2.dom  Ao  £  opi.ran 
A  {p3  £  t.dom  =>  x  =  {p3,itype{p3,t),  Extern,  t. Name)) 

A  {p3  £  t.ran  =>  x  =  (p3,otype(p3,t),t.Name,Extern}) 

A  (pi^  datastores{C)  A  pi  €  t.dom  =>■  x  =  {pi,  itype{pi,opi),  Extern,  opi. Name)) 

A  (pi^  datastores{C)  Api  £  p2.ran  =>  x  =  {pi,itype{pi,opi),op2.Name,opi.Name)) 

A  (o  ^  datastores{C)  Ao  £  t.ran  x  =  {o,  otype{o,  opi),  opi.Name,  Extern)) 

A  (pi  €  datastores{C)  =>  x  =  {dsname{pi),dstype{pi),pi,opi.Name)) 

A  {o  £  datastores{C)  =>  x  =  {dstype{o),dstype{o), opi.Name, o))}  (7.84) 
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Table  7.1  Valid  Dataflows 


Source 

Target 

Comment 

1 

Extern 

Top  Level  Process 

2 

Extern 

Subprocess 

3 

Extern 

Datastore 

Illegal 

4 

Extern 

Extern 

Illegal 

5 

Top  Level  Process 

Top  Level  Process 

Illegal 

6 

Top  Level  Process 

Subprocess 

Illegal 

7 

Top  Level  Process 

Datastore 

Constrained 

8 

Top  Level  Process 

Extern 

Subprocess 

Top  Level  Process 

Illegal 

m 

Subprocess 

Subprocess 

11 

Subprocess 

Datastore 

12 

Subprocess 

Extern 

Bl 

Datastore 

Top  Level  Process 

Constrained 

In 

Datastore 

Subprocess 

15 

Datastore 

Datastore 

Illegal 

16 

Datastore 

Extern 

Illegal 

where  the  functions  top-level  and  operations  return  the  tuple  {name,  dom,  ran)  for  each  method 
or  operation  used  in  the  axiom.  The  function  top-level  returns  only  the  signature  of  the  method 
being  deflned  while  the  function  operations  returns  a  set  consisting  of  the  signature  of  each  of  the 
methods/operations  used  to  deflne  the  “top-level”  operation. 

The  function  itype  takes  an  input  parameter  and  operation/method  name  and  returns  the 
appropriate  domain  sort  from  the  operation  or  method  signature  defined  in  C.  The  otype  function 
provides  the  same  functionality  for  an  output  parameter. 


(3  (op)  op  €  (C.Operation  U  C.Method)  A  op. Name  =  f.Name 
A  X  =  op.Domain-Ident{index{pi,  f.dom))) 

<=!>  itype{pi,  f)  =  x  (7.85) 


(3  (op)  op  €  (C.Operation  U  C.Method)  A  op. Name  =  f.Name 
A  y  =  op.Range-Ident(index(p2,  f.ran))) 

otype(p2,  f)=y  (7.86) 


The  function  dsname  returns  the  name  of  the  class  or  association  associated  with  the  data- 
store.  It  is  performed  by  finding  the  appropriate  object-valued  attribute  declaration  that  references 
the  class  set  or  association  as  defined  below. 
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(3  (a)  a  €  C.  Attribute  A  a.Name  =  d 

A  {a.Range-Ident{l)  =  name-CLASS  V  a.Range-Ident{l)- ASSOC  =  name)) 
•<=>  dsname{d)  =  name 


(7.87) 


The  function  dstype  returns  the  class  set  or  association  class  sort.  It  is  performed  by  finding 
the  appropriate  object-valued  attribute  declaration  that  references  the  class  set  or  association  as 
defined  below. 


(3  (a)  a  €  C.  Attribute  A  a.Name  =  dA  type  —  a.  Range- 1  dent  (1) 

A  {type  =  x-CLASS  V  type- ASSOC  =  a.Name)) 

•<=>  dstype{d)  =  type  (7.88) 

7.6.6  Functional  Model  Correctness  Theorem.  In  this  section,  Theorem  VII.3  establishes 
the  correctness  of  the  functional  model  translation  with  respect  to  the  functional  model  semantics 
established  in  Section  5.5.4. 

Theorem  VII.3  Given  a  valid  GOMT  domain  theory  class  C  with  a  defined  functional  model,  the 
translation  to  0-Slang  as  defined  by  t  in  Section  7.4  preserves  the  semantics  of  the  functional 
model  as  defined  in  Definition  5.5.1. 

Proof.  See  Appendix  F 

7.6.7  Communication  Correctness  Theorem.  In  this  section,  Theorem  VII.4  establishes 
the  correctness  of  the  use  of  event  theories  and  broadcast  theories  to  establish  the  global  broad¬ 
cast  communications  model  used  by  Rumbaugh.  In  essence,  the  broadcast  communications  model 
assumes  that  all  events  are  broadcast  to  the  system  and  are  received  by  all  objects  whose  dynamic 
model  have  the  capability  of  receiving  that  event.  Events  are  distinguished  by  their  names.  If  class 
A  sends  an  event  E  and  class  B  receives  an  event  E,  by  definition,  there  must  be  a  communications 
path  from  A  to  B  for  event  E. 
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Section  6.6  describes  the  use  of  event  and  broadcast  theories  to  implement  the  global  broadcast 
communications  used  in  OMT.  These  theories  are  created  by  Rules  OMT-40,  OMT-76,  OMT-77, 
OMT-78,  and  OMT-79  while  their  integration  into  aggregate  diagrams  is  defined  by  Rules  OMT-41 
and  OMT-80.  The  validity  of  these  transformations  with  respect  to  the  global  broadcast  commu¬ 
nications  model  is  shown  in  Theorem  VII.4. 

Theorem  VII.4  For  each  event  E  in  a  GOMT  domain  theory,  there  exists  a  valid  communication 
path  from  each  sending  class  A  to  each  receiving  class  B  in  the  0-Slang  domain  theory  aggregate. 

Proof.  To  be  a  valid  communications  path  from  class  A  to  class  B  for  event  E,  there  must  be 
an  operation  in  A  and  es  in  B  such  that  ca  and  Cb  are  in  the  same  equivalence  class  in  the 
domain  theory  aggregate  which  implies  that  the  associated  sorts  in  the  domain  and  range  of  ca 
and  es  are  also  in  equivalence  classes.  These  requirements  are  satisfied  by  unifying  the  operation 
signatures  and  sorts  via  the  aggregate  colimit  operation.  There  are  two  unique  cases  to  consider: 
a  single  receiving  class  and  multiple  receiving  classes.  Each  of  these  will  be  handled  separately. 

•  If  a  set  of  classes  Ai  ...  An  sends  event  E  to  a  class  B  then  Rules  OMT-76  -  OMT-79  create 
an  event  theory  ET  which  is  imported  into  each  class  A  £  A\  ...  An  by  Rule  OMT-80.  This 
importation  of  ET  defines  an  identity  morphism  mapping  each  operation  and  sort  of  ET  into 
A  (ni  in  Rule  OMT-39).  If  there  is  only  one  sending  class  (i.e.,  n  =  1)  then  the  morphism 
from  ET  to  B  (712  in  Rule  OMT-39),  as  defined  by  Rule  OMT-39,  causes  the  operations  and 
sorts  in  ET,  A,  and  B  to  be  unified  via  the  colimit  operation  in  the  aggregate  class. 

If,  however,  there  are  more  than  a  single  sending  class  (i.e.,  n  >  1),  then  by  the  definition  of 
comp-sends  and  comp-receives  in  Equations  7.12  and  7.13,  Rule  OMT-39  defines  morphisms 
from  ET  to  each  object  in  the  aggregate  that  sends  {Ai  ...  A„)  or  receives  (B),  or  whose 
components  sends  or  receives,  event  E.  Since  these  morphisms  are  formed  at  each  appropriate 
level  of  aggregation,  the  required  unification  of  the  event  operation  and  sorts  is  accomplished 
as  described  above  in  some  aggregate.  In  addition,  since  Rule  OMT-42  creates  a  top-level 
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domain  theory  aggregate  for  each  domain,  the  events  in  all  sending  classes  of  E  are  eventually 
unified  with  the  appropriate  operations  and  sorts  of  all  other  sending  and  receiving  classes  in 
the  domain  theory. 

•  If  a  set  of  classes  Ai  ...  An  sends  event  E  to  a,  set  of  classes  Bi  ...  Bm  then  Rules  OMT- 
76  -  OMT-79  create  an  event  theory  ET  which  is  imported  into  each  class  A  ^  Ai  ... 
by  Rule  OMT-80.  When  the  lowest-level  aggregate  class  is  found  whose  components  or 
subcomponents  contain  all  sending  and  receiving  classes  (i.e.,  Ai  ...  plus  Bi  ...  Bm), 
Rule  OMT-40  creates  a  broadcast  theory  BT  and  Rule  OMT-41  defines  the  appropriate 
morphisms  in  the  aggregate  diagram  such  that  the  E  event  signatures  in  sending  classes  Bi 
...  Bm  are  mapped  to  the  appropriate  operation  in  BT  and  all  receive  event  signatures  in 
receiving  classes  Ai  ...  An  are  mapped  to  their  unique  event  in  BT  defined  by  Rule  OMT- 
40.  Then  the  axioms  defined  in  the  broadcast  theory  ensure  any  that  event  received  from  a 
sending  class  Bi  is  translated  into  events  received  by  each  receiving  class  Ai  ...  An-  Finally, 
the  colimit  operation  creates  operation  and  sort  equivalence  classes  based  on  the  defined 
morphisms  completing  the  unification  process. 

□ 

7. 7  Summary 

This  chapter  presented  the  transformation  rules  necessary  to  translate  a  GOMT  AST  into  a 
valid  O- Slang  AST.  The  rules  were  specified  in  ax;cordance  with  the  various  OMT  models:  the 
object  model,  the  dynamic  model,  and  the  functional  model.  Theorems  were  presented  that  show 
that  the  transformation  rules  defined  in  this  chapter  preserve  the  semantics  of  the  restricted  OMT 
models  as  defined  in  Chapter  V.  These  rules  are  the  basis  of  an  automated  transformation  system 
described  in  Appendix  D  and  are  used  in  the  next  chapter  to  transform  two  graphically-based  OMT 
specifications  into  formal  theory-based  domain  models. 
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VIIL  Feasibility  Demonstration 


8.1  Overview 

This  chapter  demonstrates  the  feasibility  of  automatically  translating  graphically-based 
object-oriented  specifications  into  theory-based  domain  specifications.  The  theories  in  this  chapter 
were  generated  automatically  by  the  prototype  demonstration  system  described  in  Appendix  D. 
An  overview  of  each  specification  is  given,  followed  by  a  description  of  its  translation  into  theories. 

8.2  Pump  Domain 

The  Pump  domain  defines  a  specification  for  a  simple  gasoline  pump  and  is  a  modified  version 
of  the  case  study  found  in  (21).  Each  pump  may  have  multiple  hand  guns,  pump  motors,  and 
displays.  Since  I  am  modeling  a  domain,  and  not  a  system  specification,  the  exact  number  of  each 
item  is  not  important.  The  domain  object  model  is  presented  in  Section  8.2.1,  the  dynamic  model 
is  discussed  in  Section  8.2.2,  and  the  additional  textual  input  is  described  in  Section  8.2.3.  There 
is  no  functional  model  in  the  pump  domain.  The  complete  0-Slang  specification  of  the  domain 
model  is  shown  in  Appendix  G. 

8.2.1  Pump  Domain  Object  Model.  The  Pump  domain  object  model  is  shown  in  Fig¬ 
ure  8.1.  Basically,  the  specification  models  a  type  of  pump,  or  more  precisely,  two  types  of  pumps 
-  sophisticated  and  regular  -  that  are  subtypes  of  a  basic  pump  class.  Each  object  in  a  pump 
class  has  a  Pump-ID  attribute  and  consists  of  zero  or  more  Gun-Holster- Assemblies,  Clutch-Motor- 
Assemblies,  and  Displays.  Each  Gun-Holster-Assembly  object  consists  of  a  Gun  object  and  a  Holster 
object.  While  both  the  Gun  and  Holster  classes  appear  to  be  simple  classes  with  no  attributes,  a 
peek  forward  at  their  dynamic  models  (Figures  8.5  and  8.6)  shows  that  their  dynamic  models  are 
non-trivial  and  thus  they  are  valid  objects  in  the  domain  (i.e.,  they  have  state  attributes).  Likewise, 
a  Clutch-Motor-Assembly  object  has  exactly  two  components.  Motor  and  Clutch,  which  also  are 
defined  by  their  dynamic  models. 


8-1 


Figure  8.1  Pump  Domain  Object  Model 


The  Display  class  has  a  more  typical  appearance  than  the  Gun,  Holster,  Motor,  or  Clutch 
classes  in  that  it  has  four  attributes:  cost,  volume,  ppg,  and  grade.  The  underscore  in  front  of  the 
ppg  attribute  denotes  that  it  is  a  derived  attribute  (the  usual  derived  attribute  character  “/”  could 
not  be  captured  appropriately  by  the  tool)  and  its  value  for  a  given  object  is  equal  to  the  object’s 
cost  attribute  value  divided  by  the  object’s  volume  attribute  value. 

Each  class  in  the  object  model  generates  a  class  and  class  set  specification.  Since  this  trans¬ 
lation  is  the  same  for  each  class,  I  only  present  one  such  translation  in  detail,  the  Display  class. 
The  0-Slang  translations  for  the  remainder  of  the  classes  are  shown  in  Appendix  G.  The  Display 
class  specification,  as  generated  strictly  from  the  object  model,  is  shown  below.  The  specification 
itself,  along  with  the  class  sort,  is  created  by  Rule  OMT-1.  The  normal  attributes  cost,  volume, 
and  grade  are  translated  into  functions  over  the  class  sort  as  defined  by  Rule  OMT-13  while  the 
derived  attribute  ppg  is  defined  by  the  user  supplied  axiom  and  is  generated  by  Rule  OMT-14.  Since 


8-2 


there  are  normal  attributes  defined  for  the  Display  class,  Rule  OMT-15  requires  that  an  attr-eqml 
operation  be  defined.  The  axiom  is  also  automatically  generated  based  on  the  normal  attributes  of 
the  specification.  Finally,  the  specification  names  grade,  amount,  and  volume  are  included  in  the 
imports  block  of  the  specification  by  Rule  OMT-92. 


class  DISPLAY  is 

class-sort  DISPLAY 

import  GRADE,  AMOUNT,  VOLUME 

operations  ATTR-EQUAL  :  DISPLAY,  DISPLAY  ->  BOOLEAN 
attributes 

COST  ;  DISPLAY  ->  AMOUNT 
VOLUME  :  DISPLAY  —  VOLUME 
PPG  :  DISPLAY  -►  AMOUNT 
GRADE  ;  DISPLAY  -►  GRADE 
axioms 

ATTR-EQUAL{D1,  D2)  <=>  (GRADE(Dl)  =  GRADE{D2) 

&  VOLUME(Dl)  =  VOLUME{D2) 

&  COSTiDl)  =  COST{D2))-, 

PPG{D)  =  COST{D)/VOLUME(D) 
end-class 


Rule  OMT-19  requires  there  be  a  class  set  specification  for  each  class  specification  in  a  domain 
theory.  The  class  set  for  the  Display  class  is  shown  below.  The  class  name,  class  sort  name,  and 
contained  class  name  are  all  defined  by  Rule  OMT-19  based  on  the  Display  class.  Although  not 
defined  in  the  object  model.  Rule  OMT-21  requires  that  each  event  defined  in  the  basic  class  be 
defined  in  the  class  set  over  the  class  set  sort.  This  class  set  event  distributes  the  event  to  all 
objects  in  the  class  set  as  defined  by  the  axiom  generated  by  Rule  OMT-22.  Since  the  class  set  is 
simply  a  set  of  objects,  the  new  event  is  defined  by  Rule  OMT-23  to  be  simply  an  empty  set. 


class  DISPLAY-CLASS  is 

class-sort  DISPLAY-CLASS 
contained-class  DISPLAY 
events 

RESET-DISPLAY  ;  DISPLAY-CLASS  —  DISPLAY-CLASS 
PULSE  :  DISPLAY-CLASS  —  DISPLAY-CLASS 
NEW-DISPLAY-CLASS  ;  ->  DISPLAY-CLASS 
axioms 

NEW-DISPLAY-CLASSO  =  EMPTY-SET; 

fa  (D  :  DISPLAY,  DC  ;  DISPLAY-CLASS)  in(D,DC)  <=>  in{PULSE(D),  PULSE{DC)); 
fa  {D  :  DISPLAY,  DC  ;  DISPLAY-CLASS)  in(D,DC) 

<=>  in(RESET-DISPLAY{D),  RESET-DISPLAY{DC)); 

end-class 
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The  Pump,  Clutch-Motor-Assembly,  and  Gun-Holster-Assembly  classes  are  aggregate  classes, 
and  as  such  have  a  slightly  dilferent  translation.  Again  I  only  show  the  translation  details  of  one 
class,  the  Gun-Holster-Assembly  aggregate  class,  while  the  rest  are  documented  in  Appendix  G. 
Because  the  Gun-Holster-Assembly  class  is  an  aggregate  class,  Rule  OMT-24  requires  the  creation 
of  an  “aggregate”  specification  which  defines  a  diagram  in  the  category  Spec.  This  diagram 
specification,  Gun-Holster-Assembly-Aggregate,  consists  of  a  set  of  nodes  (specifications)  defined 
by  Rules  OMT-25  through  OMT-39.  In  this  case,  the  nodes  consist  of  the  event  theories  sent 
or  received  by  components  of  the  Gun-Holster-Assembly  as  well  as  the  component  specifications 
themselves.  The  arcs  are  based  on  the  nodes  in  the  diagram  and  are  defined  by  Rules  OMT-32 
through  OMT-38. 


aggregate  GUN-HOLSTER-ASSEMBLY-AGGREGATE  is 

nodes  RELEASE-HOLSTER-SWITCH,  FREE-CLUTCH,  ENGAGE-CLUTCH, 

CLOSE-HOLSTER-SWITCH,  DISABLE-PUMP,  START-TIMER,  GUN-CLASS, 
GUN,  HOLSTER-CLASS,  HOLSTER 
arcs  RELEASE-HOLSTER-SWITCH  —  HOLSTER  : 

{RELEASE-HOLSTER-SWITCH-SORT  -►  HOLSTER}, 
CLOSE-HOLSTER-SWITCH  -*  HOLSTER  : 

{CLOSE-HOLSTER-SWITCH-SORT  —  HOLSTER}, 

GUN  -*  GUN-CLASS  ■.  {}, 

HOLSTER  ->  HOLSTER-CLASS  :  {}, 

RELEASE-HOLSTER-SWITCH  GUN  :  {}, 

FREE-CLUTCH  —  GUN  :  {}, 

ENGAGE-CLUTCH  —  GUN  :  {}, 

CLOSE-HOLSTER-SWITCH  —  GUN  :  {}, 

DISABLE-PUMP  GUN  :  {}, 

START-TIMER  -►  GUN  :  {} 
end-aggregate 


Once  the  aggregate  specification  is  complete,  it  is  imported  into  the  Gun-Holster-Assembly 
specification  as  defined  by  Rule  OMT-7.  This  effectively  imports  every  specification  that  is  part  of 
the  diagram  defined  by  the  aggregate  specification  into  the  Gun-Holster-Assembly.  This  specifica¬ 
tion  is  the  same  as  a  normal  class  specification  as  defined  above  for  the  Display  class  with  a  couple 
of  extensions.  First,  in  order  to  reference  its  components,  an  object-valued  attribute  is  created  for 
each  aggregate  component  (or  set  of  components)  as  defined  by  Rule  OMT-5.  These  object- valued 
attributes  are  the  Gun-Obj  and  Holster-Obj  attributes.  Second,  the  multiplicities  of  the  component 
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must  be  axiomatized  as  defined  by  Rules  OMT-8  through  OMT-12.  In  this  case,  there  is  exactly 
one  of  each  component  and  thus  the  axiom  is  of  the  form  SIZE{HOLSTER-OBJ{G))  —  1. 


class  GUN-HOLSTER-ASSEMBLY  is 

class-sort  GUN-HOLSTER-ASSEMBLY 

import  GUN-HOLSTER- ASSEMBLY-AGGREGATE 

attributes 

GUN-OBJ  ;  GUN-HOLSTER-ASSEMBLY  -►  GUN-CLASS 
HOLSTER-OBJ  ;  GUN-HOLSTER-ASSEMBLY  HOLSTER-CLASS 
methodsCREATE-GUN-HOLSTER-ASSEMBLY  :  GUN-HOLSTER- ASSEMBLY 
eventsNEW-GUN-HOLSTER-ASSEMBLY  :  -►  GUN-HOLSTER-ASSEMBLY 
axioms 

ATTR-EQUAL(G1,  G2)  <=>  (HOLSTER-OBJ(Gl)  -  HOLSTER-OBJ{G2) 

&  GUN-OBJ{Gl)  =  GUN-OBJ{G2)y, 

ATTR-EQUAL(NEW-GUN-HOLSTER- ASSEMBLY  {),C  RE  ATE-GUN-HOLSTER-ASSEMBLY{)y, 
SIZE{HOLSTER-OBJ{G))  =  Ij 
SIZE{GUN-OBJ(G))  =  1 
end-class 


There  are  two  cases  of  inheritance  in  the  Pump  domain  object  model.  I  concentrate  on  the 
Sophisticated  pump  class  as  it  is  the  most  interesting.  The  Sophisticated  pump  class  specification  is 
shown  below  and  looks  exactly  like  a  typical  class  specification  with  a  couple  of  extensions.  First, 
the  subclass  specification  {Sophisticated)  imports  the  superclass  specification  {Pump)  as  defined 
by  Rule  OMT-3  while  the  class  sort  of  the  subclass  {Sophisticate)  is  defined  as  a  subsort  of  the 
superclass  class  sort  as  defined  by  Rule  OMT-4. 


class  SOPHISTICATED  is 

class-sort  SOPHISTICATED  <  PUMP 
import  PUMP 

operations  ATTR-EQUAL  ;  SOPHISTICATED,  SOPHISTICATED  BOOLEAN 
attributes 

VOLUME-SELECT  ;  SOPHISTICATED  -*  VOLUME 

AMOUNT-SELECT  :  SOPHISTICATED  AMOUNT 
methods 

CREATE-SOPHISTICATED  :  SOPHISTICATED 
events 

NEW-SOPHISTICATED  :  —  SOPHISTICATED 
axioms 

ATTR-EQUAL(S1,  S2)  <=>  (PUMP.ATTR-EQU AL{S1,  S2) 

&  AMOUNT-SELECT(Sl)  =  AMOUNT-SELECT(S2) 

&  VOLUME-SELECT(Sl)  =  VOLUME-SELECT{S2)y 

AMOUNT-SELECT(CREATE-SOPHISTICATED{S))  =  0; 

VOLUME-SELECT(CREATE-SOPHISTICATED{S))  =  0; 

ATTR-EQU  AL(NEW-SOPHISTICATED{yCRE  ATE-SOPHISTIC  ATED{)) 
end-class 


8-5 


The  only  other  extension  required  for  a  subclass  is  that  its  class  set  must  import  the  class  set 
of  the  superclass  as  defined  by  Rule  OMT-20  as  shown  below. 


class  SOPHISTICATED-CLASS  is 

class-sort  SOPHISTICATED-CLASS 
contained- class  SOPHISTICATED 
import  PUMP-CLASS 

events  NEW-SOPHISTICATED-CLASS  ;  -+  SOPHISTICATED-CLASS 
axioms  NEW-SOPHISTIC ATED-CLASSQ  =  EMPTY-SET 
end-class 


8.2.2  Pump  Domain  Dynamic  Model.  The  unique  aspects  of  the  dynamic  model  for 
each  class  are  described  below,  starting  with  those  of  the  Display  class  as  shown  in  Figure  8.2. 
Besides  the  initial  state,  there  are  exactly  two  states:  zero-display  and  increment- display.  The 
transition  new- display /create- display  corresponds  to  the  “new”  event  and  “create”  method  discussed 
in  Section  6.2.4.  The  transitions  between  states  are  relatively  simple  and  each  consists  of  an  event 
with  an  associated  action. 


Figure  8.2  Display  Class  Dynamic  Model 
The  axioms  derived  from  the  Display  class  dynamic  model  are  shown  below. 
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ZERO-DISPLAY  <>  INCREMENT-DISPLAY; 


(8.1) 


{DISPLAY-STATE(NEW-DISPLAY{D))  =  ZERO-DISPLAY 

&  ATTR-EQUAL(NEW-DISPLAY(D),GRBATE-DISPLAY{D)));  (8.2) 

(DISPLAY-STATE(D)  =  ZERO-DISPLAY)  => 

(DISPLAY-STATE(PULSE(D))  =  INCREMENT-DISPLAY 

&  ATTR-EQUAL{PULSE(D),  UPDATB-DISPLAY{D)));  (8.3) 

{DISPLAY-STATE{D)  =  INCREMENT-DISPLAY)  => 

{DISPLAY-STATE{RESET-DISPLAY(D))  =  ZERO-DISPLAY 

&  ATTR-EQUAL(RESET-DISPLAY(D),  ZERO-OUT-DISPLAY{D)));  (8.4) 

(DISPLAY-STATE{D)  =  INCREMENT-DISPLAY)  => 

(DISPLAY-STATE(PULSE(D))  =  INCREMENT-DISPLAY 

&  ATTR-EQUAL(PULSE(D),  UPDATE-DISPLAY(D)));  (8.5) 

DISPLAY-STATE(D)  =  ZERO-DISPLAY  => 

DISPLAY-STATE(RESET-DISPLAY{D))  =  ZERO-DISPLAY;  (8.6) 

DISPLAY-STATE(D)  =  ZERO-DISPLAY  => 

DISPLAY-STATE(PULSE(D))  =  ZERO-DISPLAY;  (8.7) 

DISPLAY-STATE{D)  -  INCREMENT-DISPLAY  => 

DISPLAY-STATE{PULSE{D))  =  INCREMENT-DISPLAY;  (8.8) 


Equation  8.1  ensures  that  the  two  states  defined  in  Figure  8.2  are  unique,  and  is  created  by 
Rule  OMT-69.  Equations  8.3,  8.4,  and  8.5  are  defined  by  the  three  transition  arrows  in  the  graphical 
representation  of  the  dynamic  model  as  shown  in  Figure  8.2.  These  three  axioms  are  created  by 
Rule  OMT-82  where  the  guard-condition  and  event-sends  parts  of  the  axiom  are  trivially  true  since 
they  are  not  defined  in  Figure  8.2.  The  final  three  axioms,  Equations  8.6,  8.7,  and  8.8  are  created 
by  Rule  OMT-84  that  ensures  no  other  transitions  may  be  added  to  the  model. 

The  Clutch  dynamic  model  is  shown  in  Figure  8.3.  The  creation  of  the  0-Slang  axioms  that 
define  Clutch  dynamic  model  is  very  similar  to  the  Display  dynamic  model  with  the  exception  of 
a  send  action  on  the  transition  from  clutch-free  to  clutch-engaged.  The  axiom  generated  by  this 
transition  is  shown  in  Equation  8.9  while  the  full  definition  of  the  Clutch  dynamic  model  is  shown 
in  Appendix  G. 

{CLUTCH-STATE{C)  =  CLUTCH-FREE)  -> 

(CLUTCH-STATE(ENGAGE-CLUTCH{C))  =  CLUTCH-ENGAGED 

&  start-fuel-obj(engage-clutch[c)) 

=  START-FUEL{START-FUEL-OBJ(C)));  (8.9) 
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Figure  8.3  Clutch  Class  Dynamic  Model 


Equation  8.9  uses  the  start-fuel-obj  object-valued  attribute  and  start-fuel  event  defined  by 
Rules  OMT-81  and  OMT-77  through  OMT-80  to  “send”  the  event  engage-clutch. 

The  Motor  class  dynamic  model  is  shown  in  Figure  8.4.  Its  translation  is  similar  to  that  of 
the  Clutch  class  above  and  its  0-Slang  representation  is  shown  in  Appendix  G. 

The  Gun  dynamic  model  is  shown  in  Figure  8.5.  It  is  similar  to  the  dynamic  model  presented 
above  except  for  the  replace-gun  transition  from  state  gun-enabled  to  gun-disabled  that  sends  three 
different  events.  The  axioms  generated  by  the  replace-gun  transition  are  shown  in  below. 


(GUN-STATE{G)  =  GUN-ENABLED)  => 

{GUN-STATE(REPLACE-GUN(G))  =  GUN-DISABLED 
&  START-TIMER-OBJ(REPLAGE-GUN(G)) 

=  START-TIMER(START-TIMER-OBJ(G)) 

&  DISABLE-PUMP-OBJ{REPLACE-GUN{G)) 

=  DISABLE-PUMP{DISABLB-PUMP-OBJ{G)) 

&  CLOSE-HOLSTER-SWITCH-OBJ{REPLACE-GUN{G)) 

=  CLOSB-HOLSTER-SWITCH{CLOSE-HOLSTER-SWITGH-OBJ{G))y,  (8.10) 
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Figure  8.4  Motor  Class  Dynamic  Model 
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This  example  shows  clearly  the  use  of  a  separate  object- valued  attribute  for  each  event  sent,  even 
though  those  events  might  actually  be  sent  to  the  same  object.  This  ambiguity  is  acceptable  since 
0-Slang  is  only  representing  a  domain  model  at  this  point. 

The  Holster  class  dynamic  model  shown  in  Figure  8.6  is  relatively  simple  and  similar  to  the  dy¬ 
namic  models  discussed  above.  No  further  clarification  of  its  translation  (as  shown  in  Appendix  G) 
is  required. 


Figure  8.6  Holster  Class  Dynamic  Model 


The  Pump  dynamic  model  (Figure  8.7)  introduces  two  new  transition  features:  parameters 
and  guards.  Actually,  both  of  these  features  are  incorporated  into  the  enable-pump  transition 
from  state  pump-disabled  to  pump-enabled.  The  parameter  x  of  type  pump-id  is  received  by  the 
pump  object  with  the  enable-pump  event.  If  the  pump  is  in  the  disabled-pump  state  and  the  guard 
condition  x  =  pump-id  is  true,  then  the  transition  takes  place.  Again,  this  transition  is  converted 
to  0-Slang  by  Rule  OMT-82  and  is  shown  below. 
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Figure  8.7  Pump  Class  Dynamic  Model 


(PUMP-STATE(P)  =  PUMP-DISABLED  &:  (X  =  PUMP-ID(P))) 

=  >  (PUMP-STATE(ENABLE-PUMP(P,  X))  =  PUMP-ENABLED 
&  RESET-DISPLAY-OBJ(ENABLE-PUMP(P,  X)) 

=  RESET-DISPLAY(RESBT-DISPLAY-OBJ{P)) 

&  START-PUMP-MOTOR-OBJ(ENABLE-PUMP{P,  X)) 

=  START-PUMP-MOTORiSTART-PUMP-MOTOR-OBJ{P)))-,  (8.11) 


Equation  8.11  inserts  the  guard  condition  {X  =  PUMP-ID{P))  before  the  implication  to  en¬ 
sure  the  condition  holds  before  forcing  the  events  start-pump-motor  and  reset-display  to  be  sent. 
As  defined  by  Assumption  V.4,  the  user  is  responsible  for  ensuring  the  completeness  and  consis¬ 
tency  of  guard  conditions  used  in  a  dynamic  model;  therefore,  the  enable-pump  transition  from 
pump-disabled  to  pump-disabled  with  a  guard  condition  of  {X  <>  PUMP-ID{P))  is  added.  The 
transition  is  shown  below  in  0-Slang  syntax. 

(PUMP-STATE{P)  =  PUMP-DISABLED  &  {X  <>  PUMP-ID{P))) 

=>  (PUMP-STATE{ENABLE-PUMP{P,  X))  =  PUMP-DISABLED  (8.12) 
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class-constraints:  Display 

display-state (d)  =  zero-display  =>  cost(d)  =  0  &  volume (d)  =  0; 
display-state (d)  =  increment-display  =>  cost(d)  >=  0  &  volume (d)  >=  0; 
cost(d)  >=  0; 
volume (d)  >=  0 
end  class-constraints. 

definition:  update-display  class  =  display; 

grade (update-display(d))  =  grade(d); 
cost (update-display (d))  =  cost(d)  +  1; 
volume (update-display (d))  =  volume (d)  +  1 
end  definition. 

definition:  zero-out-display  class  =  display; 

grade (zero-out-display (d))  =  grade(d); 
cost (zero-out-display (d))  =  0; 
volume (zero-out-display (d))  =  0 
end  definition. 


Figure  8.8  Pump  MANUAL.TEXT  File 

8.2.3  Pump  MANUAL.TEXT.  The  MANUAL.TEXT  as  shown  in  Figure  8.8  is  used 
in  the  Pump  domain  model  to  define  constraints  on  the  Display  class  and  to  add  the  semantics 
for  two  display  operations:  update- display  and  zero-out-display.  Basically,  the  body  of  these  three 
declarations  are  0-Slang  axioms  which  are  incorporated  directly  into  the  axiom  block  of  the 
Display  class  as  shown  in  Appendix  G. 


8.3  Faculty  Student  Database  Domain 

The  Faculty  Student  Database  domain  defines  a  specification  for  a  simple  school  database. 
The  database  consists  of  a  set  of  records  for  students,  faculty,  courses,  classes,  sections  and  quarters 
and  are  related  by  a  set  of  associations.  The  domain  object  model  is  presented  in  Section  8.3.1, 
the  functional  model  is  discussed  in  Section  8.3.2,  and  the  additional  textual  input  is  defined  in 
Section  8.3.3.  There  is  no  dynamic  model  in  the  faculty  student  database  domain.  The  0-Slang 
specification  of  the  domain  model  is  shown  in  Appendix  G. 
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8.3.1  Faculty  Student  Database  Domain  Object  Model.  Figure  8.9  shows  the  object  model 
for  the  faculty  student  database  domain  model.  Since  the  classes  in  the  object  model  are  relatively 


straightforward,  I  do  not  discuss  them  in  detail  as  they  are  translated  exactly  like  the  classes 
of  the  Pump  domain  in  Section  8.2.1.  Their  O-Slang  specifications  are  shown  in  Appendix  G. 
Instead  I  concentrate  on  the  associations  defined  in  the  domain  object  model:  member-of,  advises, 
teaching,  taught-as,  offering,  scheduled-in,  and  teaches.  The  first  six  associations  listed  are  basically 
identical  in  that  they  are  simple  binary  associations  between  two  classes.  The  only  difference  in 
their  definitions  is  the  multiplicity  axioms  used.  The  last  association,  teaches,  is  unique  in  that 
it  has  two  link  attributes  defined;  times-taught  and  average-size.  I  first  discuss  the  member-of 
association  as  an  example  of  the  six  simple  binary  relations  followed  by  a  detailed  description  of 


the  teaches  relation. 


Figure  8.9  Faculty-Student  Database  Object  Model 


As  described  in  Section  6.4,  the  theory-based  object  model  defines  two  specifications  for  each 
association:  a  link  specification  and  an  association  specification.  The  link  specification  defines 
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a  class  of  objects  with  attribute-valued  objects  that  reference  particular  objects  involved  in  a 
relationship  as  well  as  any  link  attributes  or  operations.  The  association  specification,  on  the  other 
hand,  is  analogous  to  a  class  set  specification  and  is  used  to  the  define  the  set  of  links  and  any 
multiplicity  constraints.  The  link  specification  for  the  member-o/ association  is  shown  below. 


link  MEMBER-OF-LINK  is 

class-sort  MEMBER-OF-LINK 
sort  STUDENT,  A-GLASS 

operations  ATTR-EQUAL  :  MEMBER-OF-LINK,  MEMBER-OF-LINK  -*  BOOLEAN 
attributes 

A-CLASS-OBJ  :  MEMBER-OF-LINK  —  A-CLASS 
STUDENT-OBJ  ;  MEMBER-OF-LINK  —  STUDENT 
methods  CREATE-MEMBER-OF-LINK  :  A-CLASS,  STUD  ENT  —  MEMBER-OF-LINK 
events  NEW-MEMBER-OF-LINK  :  A-CLASS, STUDENT  MEMBER-OF-LINK 
axioms 

ATTR-BQUAL(M1,  M2)  <=>  (STUDENT-OBJ (Ml)  =  STUDENT-OBJ(M2) 

&  A-CLASS-OBJ(Ml)  =  A-CLASS-OBJ(M2))-, 
STUDENT-OBJ(CREATE-MEMBER-OF-LINK(M,  S,A))  =  S-, 
A-CLASS-OBJ(CREATE-MEMBER-OF-LINK(M,  S,A))  =  A; 

ATTR-EQUAL(NEW-MEMBER-OF-LINK(M,  S,  A),  (C REATE-MEMBER-OF-LIN K(M,  S,A))) 
end-link 


Rule  OMT-43  actually  creates  the  specification  and  the  class  sort.  The  sorts  student  and  a-class 
are  unified  with  the  class  sort  of  the  associated  classes  in  the  appropriate  aggregate  layer  and  are 
defined  by  Rule  OMT-47.  The  attributes  a-class-obj  and  student-obj  are  object-valued  attributes 
that  reference  objects  from  their  respective  classes  and  are  defined  by  Rule  OMT-61.  The  attr-equal, 
create,  and  new  operations  are  defined  the  same  as  for  simple  classes  in  the  object  model. 

The  association  specification  for  memher-of  is  shown  below.  The  basic  specification,  class 
sort,  and  link  class  are  defined  in  Rule  OMT-44.  The  sorts  student-class  and  a-class-class  are  to 
be  unified  with  the  class  set  sorts  of  the  associated  classes  and  are  defined  by  Rule  OMT-45. 


association  MEMBER-OF  is 
class-sort  MEMBER-OF 
link-class  MEMBER-OF-LINK 
sort  STUDENT-CLASS,  A-CLASS-CLASS 
operations 

IMAGE  ;  MEMBER-OF,  STUDENT  A-CLASS-CLASS 

IMAGE  ;  MEMBER-OF,  A-CLASS  ->  STUDENT-CLASS 
eventsNEW-MEMBER-OF  MEMBER-OF 
axioms 

NEW-MEMBER-OF()  =  EMPTY-SET; 

fa  (M  :  MEMBER-OF,  S  :  STUDENT)SIZE(IMAGE(M,  S))  =  1; 

fa  (M  :  MEMBER-OF,  A  ■.  A-CLASS)SIZE(IMAGE(A,X))  >=  0 
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fa  {S  ;  MEMBER-OF,  M  i  STUDENT,  B  ;  A-CLASS) 

{ex(A  ;  MEMBER-OF-LINK)in(A,  S) 

&  MEMBER-OF-OBJ(A)  =  M  &  MEMBER-OF-OBJ(A)  =  B) 
<=>  in(B,  image{S,  Af)); 

fa  (S  :  MEMBER-OF,  M  :  STUDENT,  B  ;  A-CLASS) 

{ex(A  :  MEMBER-OF-LINK)in{A,  S) 

&  MEMBER-OF-OBJ(A)  =  B  &  MEMBER-OF-OBJ{A)  =  M) 
<=>  in(M,image(S,  B)) 
end-association 


In  order  to  constrain  the  multiplicities  of  objects  in  the  association,  an  image  operation  is  created 
for  each  class  in  the  association.  Therefore,  in  the  memher-of  association.  Rule  OMT-46  requires 
the  definition  of  two  image  operations,  each  returning  the  set  of  objects  associated  with  a  given 
object  as  shown  below. 

fa  (M  ;  MEMBER-OF,  S  :  STUDENT)SIZB{IMAGE{M,  S))  =  1 
fa  (M  ■.  MEMBER-OF,  A:  A-CLASS)SIZE{IMAGE(A,X))  >=  0 

The  second  multiplicity  axiom  shown  is  not  actually  included  in  the  automatically  generated  O- 
Slang  in  Appendix  G  since  by  definition,  the  size  of  any  set  is  always  greater  than  or  equal  to 
zero. 


8.3.2  Faculty  Student  Database  Domain  Functional  Model.  There  are  actually  two  func¬ 
tional  models  for  the  Faculty  Student  Database  domain.  The  first  is  the  Faculty  Workload  functional 
model  found  in  Section  G.2.  The  second,  the  Update- Teaches  model,  is  shown  in  Figure  8.10  and 
is  further  refined  in  Figure  8.11.  Both  models  are  translated  into  0-Slang  in  the  same  manner; 
however,  since  the  Update-Teaches  function  has  fewer  subprocesses  while  incorporating  more  as¬ 
pects  of  the  OMT  functional  model,  I  discuss  its  functional  model  translation  in  detail  here.  The 
0-Slang  for  the  Faculty- Workload  function  is  defined  in  Appendix  G. 

The  top-level  diagram  for  the  Update-Teaches  function  is  shown  in  Figure  8.10.  There  are 
three  explicit  inputs  to  the  function:  name,  type,  and  num;  however,  by  Rule  OMT-85,  the  object 
upon  which  the  function  works  is  also  an  input.  Because,  as  shown  in  Figure  8.11,  a  subprocess  of 
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Figure  8.10  Update-Teaches  Functional  Model 


Figure  8.11  Update-Teaches  Functional  Model  Level  2 


Update-Teaches  {modify-teaches)  modifies  the  Teaches  association,  Update- Teaches  is  a  method  as 
shown  below  by  its  signature. 


UPDATE-TEACHES  :  FACULTY-WORKLOAD,  NUM,  NAME,  TYPE  —  FACULTY-WORKLOAD 

Update-Teaches  is  a  method  in  the  Faculty  Workload  class  since  the  process  modify-teaches, 
a  subprocess  of  Faculty  Workload,  modifies  the  Teaches  association  as  shown  in  Figure  8.11.  The 
remaining  operation  signatures  as  defined  by  Rule  OMT-85  or  Rule  OMT-86  are  shown  below. 


GET-FACULTY  ;  FACULTY-CLASS,  NAME  —  FACULTY 
GET-COURSE  ;  COURSE-CLASS,  NUM,  TYPE  COURSE 

GET-SECTION S-T AUGHT  :  SECTION-CLASS,  FACULTY  —  SECTION-CLASS 
GET-SECTION S-OFFERED  ;  SECTION-CLASS, COURSE  -*  SECTION-CLASS 
COMPUTE-SECTION-UNION  ;  SECTION-CLASS,  SECTION-CLASS  -*  TIMES-TAUGHT 
COUNT-TIMES-T AUGHT  ;  SECTION-CLASS,  COURSE,  FACULTY  —  TIMES-TAUGHT 
GET-TEACHES  :  TEAC HES,  FAGULTY,COURSB  —  TEACHES-LINK 
MODIFY-TEACHES  ;  TEACHES,TIMES-TAUGHT,  TEACHES-LINK  TEACHES 


The  implementing  axiom  for  the  method  Update-Teaches  as  defined  by  Rule  OMT-87  is 
shown  below.  The  parameters  come  directly  from  the  functional  model  diagram  with  the  exception 
of  the  datastores  (classes  and  associations).  Datastore  names  are  translated  to  their  object- valued 
attribute  names.  The  operation  Count- Times- Taught  has  a  similar  definition  based  on  its  functional 
model  as  shown  in  Figure  8.12.  The  0-Slang  translation  of  the  implementing  axioms  for  Count- 
Times-Taught  is  shown  in  Appendix  G. 


UPDATE-TEACHES{F,NUM,  NAME,TYPE)  =  FI 
&  TEACHES-OBJ{Fl) 

=  MODIFY-TEACHES{TEACHES-OBJ(F),TIMES-T AUGHT,  TEACHES-LINK) 

&  TEACHES-LINK  =  GET-TEACHES(TEACHES-OBJ{F),  FACULTY,  COURSE) 

&  TIMES-TAUGHT  =  COUNT-TIMES-TAUGHT(SECTION-OBJ{F),  COURSE,  FACULTY) 
&  COURSE  =  GET-COURSE{COURSE-OBJ(F),  NUM,  TYPE) 

&  FACULTY  =  GET-FACULTY{FACULTY-OBJ{F),NAME)-, 


8.3.3  Faculty  Student  Database  MANUAL.  TEXT.  The  Faculty  Student  Database  MAN¬ 
UAL. TEXT  Hie  (Figure  8.13)  is  used  to  define  super/subprocess  relationships.  In  this  example,  the 
“leaf”  processes  semantics  are  not  included  for  simplicity;  however,  the  process  definitions  would 
be  similar  to  update- display  and  zero- out- display  shown  in  Figure  8.8. 
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Figure  8.12  Count-Times-Taught  Functional  Model 


subprocess  get-faculty  <  process  cal culate-f acuity-workload, 
subprocess  calculate-course-load  <  process  calculate-f acuity-workload, 
subprocess  calculate-student-load  <  process  calculate-f acuity-workload, 
subprocess  calculate-workload  <  process  calculate-f acuity-workload, 
subprocess  get-sections  <  process  calculate-course-load. 
subprocess  compute-credits  <  process  calculate-course-load. 
subprocess  get-students-advised  <  process  calculate-student-load. 
subprocess  count-students  <  process  calculate-student-load. 

subprocess  get-faculty  <  process  update-teaches . 
subprocess  get-course  <  process  update-teaches. 
subprocess  count-times-taught  <  process  update-teaches. 
subprocess  get-teaches  <  process  update-teaches. 
subprocess  modify-teaches  <  process  update-teaches. 

subprocess  get-sections-taught  <  process  count-times-taught. 
subprocess  get-sections-off ered  <  process  count-times-taught. 
subprocess  compute-section-union  <  process  count-times-taught. 

Figure  8.13  Faculty  Student  Database  MANUAL.TEXT  File 
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8.^  Summary 


This  chapter  presented  two  examples  of  the  automated  translation  of  graphically-based  do¬ 
main  model  specifications  into  O- Slang  using  the  translations  defined  in  Chapter  VII.  The  first 
example,  the  Pump  domain,  was  almost  exclusively  dynamic  in  nature  and  showed  the  feasibility 
of  automatically  translating  dynamic  models  into  valid  theory-based  specifications.  The  second 
example,  the  Student  Faculty  Database  domain,  was  almost  purely  functional  in  nature  and  showed 
the  automatic  translation  of  the  restricted  functional  model  for  both  methods  and  operations.  This 
section  concentrated  on  instructive  features  from  both  domains;  however,  the  complete  0-Slang 
domain  model  is  contained  in  Appendix  G. 
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IX.  Conclusions  and  Recommendations 


The  purpose  of  this  research  was  to  investigate  the  feasibility  of  a  parallel  refinement  approach 
to  the  acquisition  of  formal  specifications  based  on  graphically-based,  object-oriented  concepts  and 
theory-based  algebraic  specifications.  This  investigation  focused  on  two  main  areas:  a  formal 
mathematical  framework  of  object-oriented  concepts  using  theories  within  the  category  Spec,  and 
the  automatic  translation  of  graphically-based,  object-oriented  diagrams  into  this  theory-based 
framework. 

The  first  phase  in  this  investigation  focused  on  establishing  the  formal  mathematical  frame¬ 
work  for  the  object-oriented  paradigm  within  a  categorical  setting.  First,  classes  were  defined  as 
theory  presentations  or  specifications  within  the  category  Spec  while  their  models  were  equated 
with  an  implementation  of  the  class.  The  theoretical  concept  of  an  object  instance  was  defined  and 
used  to  show  the  desired  effect  of  inheritance.  Both  single  and  multiple  inheritance  were  formally 
defined  using  category  theory  operations  on  classes.  This  formal  definition  of  inheritance  was  then 
shown  to  preserve  the  “Substitution  Property” ,  a  commonly  proposed  notion  of  what  valid  inher¬ 
itance  should  be.  Next,  a  theory-based  object  model  defining  concepts  from  Rumbaugh’s  OMT 
notation  in  the  formal  mathematical  framework  was  developed.  Because  OMT  is  a  semi-formal 
technique,  a  formal  semantics  for  each  OMT  model  was  first  defined. 

Provably  correct  translations,  with  respect  to  the  previously  defined  formal  semantics,  from 
the  restricted  OMT  models  to  a  theory-based  specification  were  then  defined.  These  translations 
map  each  concept  in  OMT  into  a  specific  representation  within  0-Slang.  To  show  the  feasibility  of 
automating  these  translations,  a  proof  of  concept  system  was  developed  which  took  OMT  models 
created  with  a  commercially  available,  graphically-based  OMT  drawing  tool  and  automatically 
translated  them  into  a  generic  abstract  syntax  tree  representation  and  then  into  0-Slang. 
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9.1  Summary  of  Contributions 


This  section  summarizes  the  contributions  of  this  research  as  enumerated  in  Chapter  1.  The 
first  contribution  is  the  formalization  of  basic  object-oriented  concepts  using  algebraic  and  category 
theory  constructs.  While  there  has  been  prior  work  on  the  formalization  of  the  individual  aspects 
of  object-orientation  (12,  14,  23,  38,  69,  94),  this  research  is  the  first  effort  to  formally  define  all 
the  important  aspects  of  object-orientation  (i.e.,  classes,  inheritance,  aggregation,  association,  and 
communication)  in  a  cohesive,  computationally  tractable  framework  that  is  applicable  to  semi¬ 
automatic  software  synthesis  (55,  86,  87). 

The  second  contribution  of  this  work  is  the  formalization  of  a  generally  accepted  notion  of 
class  inheritance,  the  Substitution  Property.  While  other  attempts  have  been  made  to  formalize 
inheritance  (12,  39),  the  use  of  category  theory  constructs  to  define  valid  inheritance  leads  naturally 
to  a  computationally  tractable  sufficiency  criteria  for  proving  adherence  to  that  formalization.  In 
fact,  adherence  to  this  formalization  of  inheritance,  along  with  aggregation  and  association,  provides 
techniques  for  ensuring  the  consistency  of  object-oriented  specifications  based  on  the  composition 
process  itself. 

The  next  contribution  of  this  effort  is  the  formalization  of  the  semantics  of  the  object,  dy¬ 
namic,  and  functional  OMT  models.  While  Harel  (45)  defined  the  semantics  of  statecharts  based  on 
traditional  automata  theory,  formalization  of  communications  paths  within  a  domain  specification 
along  with  the  object  model  and  the  functional  models  have  seen  little  work.  While  the  concept  of 
global,  event-based  communications  is  relatively  simple,  its  formalization  is  not.  However,  use  of 
category  theory  concepts  allows  the  specification  of  the  capability  of  a  class  to  communicate  with 
other  classes.  Building  on  the  work  of  Bourdeau  and  Cheng  (14),  formalization  of  the  object  model 
semantics  was  accomplished  using  specifications  to  define  classes  and  boolean-valued  predicates  to 
define  the  relationships  between  classes.  The  informal  semantics  of  the  functional  model  required 
major  restrictions  before  it  could  be  automatically  translated  into  a  formal  representation.  The 
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work  of  Tao  and  Kung  (92)  on  standard  data  flow  diagrams  was  tailored  to  my  restricted  functional 
model  in  order  to  complete  the  formalization  of  the  OMT  semantics. 

The  advances  described  above  made  possible  the  major  contribution  of  this  work,  which  is 
defining,  formalizing,  and  automating  the  translation  of  graphically-based,  object-oriented  specifi¬ 
cations  into  algebraic  specifications.  This  formalization  and  automation  of  specification  translation 
increases  the  level  of  abstraction  at  which  formal  specifications  may  be  developed  and  thus  holds 
the  potential  to  dramatically  increase  the  acceptance  of  formal  specifications  and  methods.  With¬ 
out  raising  the  level  of  abstraction  at  which  formal  specifications  can  be  developed,  specification  of 
large,  complex  systems  will  remain  too  difficult  for  the  average  software  developer,  and  the  potential 
of  formal  methods  (e.g.,  automated  software  synthesis,  etc.)  will  never  be  realized. 

9.2  Conclusions  and  Results 

Several  specific  conclusions  can  be  drawn  from  this  investigation. 

1.  The  category  Spec  provides  a  formal  foundation  for  the  rigorous  definition  of  object-oriented 
concepts.  Classes  and  associations  are  defined  as  theories.  Single  and  multiple  inheritance 
can  be  formally  modeled  and  correctly  constructed  using  specification  morphisms.  Aggregate 
objects  may  be  effectively  modeled  and  correctly  constructed  using  colimits  of  component 
classes  and  specification  morphisms. 

2.  The  semantics  of  the  OMT  models  were  formalized  by  restricting  the  informal  and  semi- 
formal  notation  allowed  in  OMT.  Formalization  of  these  semantics  allows  the  models  to  be 
automatically  translated  into  theories  in  the  category  Spec. 

3.  Translations  from  graphically-based  OMT  object,  dynamic,  and  functional  models  were  de¬ 
veloped  using  a  theory-based  model  of  object-orientation.  These  translations  were  shown  to 
correctly  translate  the  models  into  O-Slang  based  on  their  restricted  formal  semantics. 
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4.  A  category  theory-based  algebraic  specification  language,  0-Slang,  was  developed  based 
on  the  functional  algebraic  specification  language  Slang.  0-Slang  allows  object-oriented 
models  to  be  captured  naturally  using  algebraic  specifications.  0-Slang  incorporates  basic 
object-oriented  concepts  such  as  classes,  associations,  and  aggregates  as  well  as  basic  category- 
theory  operations  of  specification  morphisms,  diagrams,  and  colimits. 

5.  The  feasibility  of  creating  an  automated  translation  system  was  established  through  the  de¬ 
velopment  of  a  proof-of-concept  system  using  a  commercial  front-end  graphics  tool.  This 
proof-of-concept  tool  was  used  to  automatically  translate  non-trivial  dynamically  and  func¬ 
tionally  based  OMT  domain  models  into  algebraic  theories. 

9.3  Future  Work 

This  investigation  has  laid  the  foundation  for  the  Specification  Acquisition  Mechanism  defined 
in  Chapter  II  and  shown  again  in  Figure  9.1.  However,  to  complete  this  vision,  the  results  of  this 
investigation  must  be  extended.  Several  areas  requiring  additional  research  are  identified  and 
summarized  below. 

1.  The  generic  OMT  AST  developed  to  capture  object-oriented  concepts  from  the  three  basic 
OMT  models  should  be  analyzed  to  determine  its  capability  to  capture  object-oriented  con¬ 
cepts  using  other  object-oriented  modeling  methodologies  and  techniques.  A  single  generic 
AST  would  allow  any  number  of  methodologies  to  be  incorporated  into  an  automated  tool 
such  as  the  proof-of-concept  tool  developed  in  this  investigation.  While  the  generic  OMT 
AST  was  not  developed  with  this  more  general  purpose  in  mind,  some  object-oriented  tech¬ 
niques  appear  to  be  similar  enough  to  OMT  to  allow  their  incorporation  into  the  generic  AST 
(13,  19,  21,  84). 

2.  Investigation  of  the  transformations  required  to  develop  problem-specific  system  specifications 
from  0-Slang  domain  models  should  be  undertaken.  This  is  the  Specification  Generation 
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Figure  9.1  Parallel  Refinement  Specification  Acquisition  Mechanism 


phase  shown  in  Figure  9.1.  There  has  been  some  work  in  this  area  (49).  Some  possible 
transformations  might  include  the  following. 

(a)  parameter  instantiation 

(b)  specialization  selection 

(c)  multiplicity  restriction 

(d)  initialization  definition 

(e)  communication  path  definition 

(f)  constraint  restriction 

3.  Domain  modeling  literature  often  refers  to  providing  a  domain-specific  language  for  developing 
problem-specific  system  specifications.  In  this  research,  I  assumed  the  transformations  would 
be  accomplished  using  a  generic  object-oriented  representation.  However,  domain-specific 
graphically-based  languages  should  be  a  topic  for  further  research.  Given  a  theory-based 
domain  model,  the  domain  engineer  should  be  able  to  define  graphically-based  icons  for  classes 
of  objects  and  associations  within  the  domain  that  a  user  could  then  use  to  build  a  problem- 
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specific  specification.  Such  a  domain-specific  language  might  even  implicitly  incorporate  some 
of  the  domain  to  problem-specific  transformations  discussed  above.  Some  work  has  been  done 
in  this  area  (56). 

4.  Matching  theory-based,  problem-specific  functional  specifications  to  architecture  theories  in 
the  Specification  Structuring  phase  of  Figure  9.1  requires  additional  research.  While  theory- 
based  architecture  theories  have  been  addressed  (32),  many  problems  associated  with  auto¬ 
matically  matching  them  to  system  specifications  need  further  research.  One  such  problem 
closely  associated  with  the  object-oriented  paradigm  is  the  dynamic  creation  of  objects,  which 
requires  the  ability  to  specify  dynamically  modifiable  architectures. 

5.  The  formal,  automated  translation  of  O-Slang  to  Slang  should  be  developed.  Assuming 
the  ability  of  Specware  or  some  other  suitable  transformation  system  to  transform  Slang 
to  executable  code,  this  would  be  the  final  link  between  graphically-based  object-oriented 
specifications  and  executable  code. 

6.  The  definition  of  a  graphically-based  object-oriented  methodology  or  technique  designed 
specifically  for  formal  transformation  should  be  investigated.  While  many  graphically-based 
object-oriented  methodologies  have  been  proposed  (13,  15,  19,  20,  21,  72,  73,  84),  they  all 
have  some  degree  of  informality  or  ambiguity  associated  with  them.  Research  starting  from 
the  theory-based  object  model  and  attempting  to  develop  graphically-based  mechanisms  for 
defining  those  critical  theory-based  concepts  might  yield  some  unique,  possibly  more  efficient 
graphically-based  specification  techniques. 

7.  A  graphically-based  tool  to  work  directly  with  the  generic  OMT  AST  should  be  developed. 
Such  a  tool  could  enforce  the  assumptions  made  about  the  OMT  model  usage  and  would 
simplify  tool  development.  Also,  such  a  tool  would  aid  in  the  investigation  of  the  generic 
OMT  AST  as  well  as  an  object-oriented  methodology /technique  designed  specifically  for 
translation  to  algebraic  theories. 
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8.  0-Slang  should  be  extended  to  add  the  necessary  structuring  devices  to  ensure  a  two-way 
transformation  from  the  GOMT  AST  to  0-Slang  and  back  again.  While  it  should  not  be 
difficult  to  implement,  it  is  critical  to  the  flexibility  of  the  Parallel  Successive  Reflnement 
Approach. 

9.4  Reflections  on  the  Parallel  Successive  Reflnement  Approach 

A  Parallel  Successive  Refinement  Approach  to  specification  acquisition  was  presented  in  Chap¬ 
ter  I  and  a  Specification  Acquisition  Mechanism  based  on  such  an  approach  was  introduced  in 
Chapter  II.  In  a  true  parallel  refinement  approach,  two  versions  of  the  specification  are  kept  and 
refined  in  parallel.  In  my  Specification  Acquisition  Mechanism  I  proposed  that  two  versions  of  the 
same  specification  need  not  be  kept  assuming  the  specification  representation  could  be  automati¬ 
cally  generated.  Upon  completion  of  my  research,  I  find  I  was  correct.  (Even  though  the  two-way 
translation  is  not  yet  complete,  it  appears  clear  that  it  is  possible).  Maintaining  one  specification, 
with  multiple  representations,  is  much  simpler  than  maintaining  two  specifications  and  ensures 
consistency.  Therefore,  a  better  name  for  the  methodology  represented  by  the  system  in  Figure  9.1 
is  a  Multiple  Representation  Approach. 

The  Multiple  Representation  system  proposed  in  Figure  9.1  shows  specifications  being  stored 
in  “theory”  form;  however,  the  best  long-term  storage  format  has  not  been  ascertained,  if,  in  fact, 
it  makes  a  significant  difference.  While  it  appears  evident  that  modifications  to  domain  theories 
should  be  made  via  the  graphical  user  interface  (which  argues  for  storing  domain  theories  in  a 
graphical  format),  the  development  of  elicitor-harvester  technology  to  help  in  selecting  appropriate 
domain  theories  from  Theory  Library  might  be  more  tractable  if  domain  theories  are  stored  in  a 
theory-based  format.  It  is  also  possible  that  some  intermediate  format  such  as  the  GOMT  AST 
might  also  be  the  best  choice. 
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In  conclusion,  it  is  my  conviction  that  formal  methods  will  never  reach  their  true  potential 
unless  a  straightforward,  cost-effective  capability  for  developing  large-scale  system  specifications 
can  be  found.  From  the  experience  gained  in  this  investigation,  I  believe  a  Multiple  Representation 
Approach  is  a  viable,  if  not  the  best,  approach  to  providing  such  a  capability  in  the  near  future. 

9. 5  Summary 

Given  the  results,  contributions  and  conclusions  presented  in  this  and  previous  chapters,  it 
is  obvious  that  the  objectives  of  this  investigation  were  successfully  accomplished.  Specifically,  a 
formal  mathematical  framework  of  object-oriented  concepts  within  the  category  Spec  was  defined 
and  the  automatic  translation  of  graphically-based,  object-oriented  diagrams  into  this  theory-based 
framework  was  demonstrated.  Additionally,  several  areas  of  future  research  were  identified. 
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Appendix  A.  Generic  OMT  Abstract  Syntax  Tree 


A.l  Introduction 

This  Appendix  defines  the  generic  model  of  object-orientation  based  on  Rumbaugh’s  OMT 
(83)  that  is  used  in  my  research.  Section  A,2  defines  the  features  of  OMT  that  are  translated  to 
0-Slang  using  a  generic  OMT  (GOMT)  AST  representation.  Section  A.3  discusses  the  GOMT 
AST  objects  derived  from  class  defintions  in  the  OMT  object  model,  including  attributes  and  oper¬ 
ations,  while  Section  A.4  defines  the  AST  objects  associated  with  OMT  object  model  associations. 
Section  A. 5  presents  the  objects  of  the  GOMT  AST  derived  from  the  OMT  dynamic  model  while 
Section  A. 6  discusses  the  GOMT  AST  objects  defined  from  the  OMT  functional  model.  Complete¬ 
ness  of  the  GOMT  in  terms  of  Rumbaugh’s  OMT  representation  is  discussed  in  Section  A. 7. 

A  GOMT  AST  is  used  to  store  domain  models  specified  using  OMT  notation.  In  this  research, 
this  specification,  translation,  and  storage  is  performed  using  the  demonstration  tool  described  in 
Appendix  D.  Using  this  tool,  once  a  domain  model  is  stored  as  a  GOMT  specification  it  can  be 
automatically  translated  into  0-Slang  as  defined  in  Chapter  VII. 

The  notation  used  to  present  the  GOMT  AST  structure  follows  the  conventions  of  the  OMT 
object  model  with  two  extensions.  First,  rectangles  represent  classes  of  AST  objects  (which  may 
or  may  not  have  subobjects  or  attributes)  while  rectangles  with  rounded  corners  represent  symbols 
or  numbers  that  define  specific  attributes  associated  with  their  parent  AST  objects.  Second,  AST 
subobjects  with  multiplicities  greater  than  one  may  either  represent  a  set  of  AST  subobjects  or  a 
sequence  of  AST  subobjects.  Sets  are  denoted  by  braces  ({  })  surrounding  the  AST  object  name 
while  sequences  are  denoted  by  brackets  ([  ]). 

A. 2  Object  Modeling  Technique  Representation  Assumptions 

An  OMT  specification  has  three  basic  components:  an  object  model,  a  dynamic  model,  and  a 
functional  model.  However,  these  three  models  do  not  operate  independently,  although  Rumbaugh 
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does  not  rigorously  define  their  precise  interaction.  The  OMT  object  model  defines  the  structure 
of  a  domain  in  terms  of  the  object  classes  in  the  domain  and  the  relationships  between  them.  Each 
object  class  is  defined  in  terms  of  its  attributes  and  operations  while  the  relationships  between  them 
are  captured  via  associations,  inheritance,  and  aggregation.  The  dynamic  model  captures  the  state- 
based  behavior  of  a  class  and  is  generally  defined  at  the  class  level.  The  functional  model  describes 
how  a  domain  transforms  data  and  is  not  concerned  with  the  objects  involved  or  transformation 
timing. 

Rumbaugh  does  not  tie  the  three  models  together  tightly;  therefore,  I  made  some  assumptions 
about  the  how  the  OMT  models  are  used. 

1.  Assumption  A.l  The  object  model  is  developed  first  and  defines  all  object  classes  and  as¬ 
sociations  present  in  a  domain.  Attributes  are  defined  for  each  object  class. 

2.  Assumption  A. 2  There  is  an  implied  domain-level  aggregate  class  for  each  object  model. 
This  domain-level  object  class  is  an  aggregate  composed  of  each  object  class  and  association 
defined  in  the  object  model. 

3.  Assumption  A. 3  There  is  a  dynamic  model  for  each  object  class.  This  dynamic  model  de¬ 
fines  the  states,  events,  actions,  and  communications  for  each  object  class.  A  purely  functional 
object  class  has  one  state  and  a  unique  event  for  each  operation  defined. 

4.  Assumption  A.4  The  dynamic  model  is  represented  as  a  Mealy  state  machine  where  all 
actions  occur  on  transitions  between  states.  Non-state  attributes  values  are  not  modified 
simply  by  receiving  an  event;  a  specific  action  must  be  specified  in  response  to  a  state  transition 
in  order  to  modify  an  object’s  non-state  attribute  values. 

5.  Assumption  A. 5  Events  not  included  in  a  dynamic  model  are  assumed  to  have  no  affect  on 
the  object. 
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6.  Assumption  A. 6  Events  with  common  names  represent  the  same  event  between  all  dynamic 


models  in  a  given  domain. 

7.  Assumption  A. 7  There  is  a  functional  model  for  each  aggregate  object  class  in  the  domain. 
Aggregate  functional  models  are  used  to  define  the  effect  of  actions  specified  in  the  aggregate 
dynamic  model  across  all  components  of  the  aggregate.  They  may  not  define  the  effect  of 
aggregate  actions  on  components  outside  the  aggregate. 

8.  Assumption  A. 8  All  primitive  actions  (those  not  defined  by  afunctional  model)  are  defined 
axiomatically  using  first  order  logic  in  0-Slang  syntax.  These  definitions  completely  define 
the  effect  of  the  operation  on  each  object  attribute. 

Although  OMT  has  three  distinct  models,  it  basically  models  object  classes  and  their  rela¬ 
tionships.  The  dynamic  and  functional  OMT  models  (making  the  above  assumptions)  serve  only 
to  define  the  behavior  of  those  object  classes.  Therefore,  the  GOMT  AST  defined  in  this  Appendix 
is  based  on  a  set  of  object  classes  and  a  set  of  associations  between  them.  Figure  A.l  shows  the 
top-level  of  the  GOMT  AST.  Other  relationships  such  as  aggregation  and  inheritance  are  captured 
naturally  in  the  object  class  definitions. 


Figure  A.l  Top  Level  GOMT  Abstract  Syntax  Tree 


A. 3  Class  Objects 

The  OMT  object  model  captures  the  structure  of  a  domain  model  by  defining  the  classes  of 
objects  in  the  domain  model  in  terms  of  their  attributes  and  operations,  as  well  as  relationships 
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between  object  classes.  Each  class  describes  a  group  of  objects  with  similar  attributes  and  behavior. 
Class  relationship  constructs  include  inheritance  and  aggregation  as  well  as  associations  that  may 
exist  between  classes.  As  stated  above,  due  to  my  assumptions  about  how  OMT  is  used  to  define 
domain  models,  an  OMT  class  consists  of  object  model  class  constructs  as  well  as  dynamic  and 
functional  components.  Figure  A. 2  shows  the  AST  for  the  GOMT  “Class”.  Basic  attributes  such 
as  the  class  name,  attributes,  and  operation  definitions  are  captured  directly  in  the  AST.  Each  of 
the  subobjects  in  the  class  AST  is  discussed  below. 


Figure  A. 2  GOMT  Class  Abstract  Syntax  Tree 


The  name  attribute  is  simply  a  symbol  that  stores  the  name  of  the  class.  Inheritance  is 
captured  in  the  superclass  attribute.  The  superclass  attribute  is  just  a  set  of  symbols  representing 
the  names  of  all  superclasses. 

Aggregation  is  captured  by  a  set  of  connection  objects  as  shown  in  Figure  A. 3.  Connec¬ 
tion  objects  are  used  to  represent  aggregates  as  well  as  associations  (as  discussed  below).  Each 
connection  links  the  current  class  to  a  component  class.  The  name  attribute  is  the  name  of  the 
component  class.  The  qualifier  subobject  defines  aggregate  (or  association)  qualifiers  and  has  an 
associated  name  and  a  datatype.  Each  connection  may  also  have  a  role  name  associated  with  it 
as  defined  by  the  role  attribute.  The  role  is  simply  a  name  placed  on  one  end  of  an  aggregate  or 
association.  Finally,  the  multiplicity  of  the  component  (or  association)  connection  is  defined  by  a 
mult  subobject.  Each  connection  has  a  multiplicity  and  this  multiplicity  can  be  either  one,  many, 
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many  ordered,  one-or-more,  optional  (zero  or  one)  or  specified  by  a  subset  of  non-negative  integers. 
These  options  are  captured  in  a  mult  object.  Subtypes  of  the  multiplicity  object  -  one,  many,  plus, 
optional,  and  specified  -  capture  these  possibilities.  The  subtypes  one,  optional,  and  many  have  no 
attributes.  Their  object  type  alone  uniquely  identifies  the  multiplicity.  The  plus  subtype  actually 
captures  more  than  the  basic  one-or-more  multiplicity  as  defined  by  Rumbaugh  and  allows  a  more 
general  “n  or  more”  multiplicity  by  allowing  the  user  to  insert  any  non-negative  integer  as  the  int 
attribute.  The  specified  multiplicity  object  is  also  very  flexible.  Each  specified  object  has  a  set  of 
ranges  defined  by  the  value  attributes.  Each  spec-range  object  may  have  either  one  or  two  values. 
If  only  one  value  is  specified,  then  exactly  that  value  is  taken  as  a  valid  multiplicity.  If  two  values 
are  specified  then  the  entire  range  between  valuel  and  value2  (inclusive)  is  a  valid  range. 


Figure  A.3  Connection  Abstract  Syntax  Tree 


Class-level  constraints  are  captured  via  the  class  object’s  constraints  subobject.  This  con¬ 
straint  object  is  actually  a  set  of  axiom  objects  defined  below.  In  my  research,  the  axiom  objects 
are  first-order  algebraic  axioms;  however,  in  general,  the  axiom  object  definition  may  be  replaced 
by  any  axiom  notational  style.  Therefore,  other  notations  such  as  Z’s  set-based  syntax,  could  be 
inserted  as  well. 
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Each  class  dynamic  model  is  captured  by  the  states  and  transitions  objects.  Each  of  these 
objects  are  sets  of  subobjects  that  define  the  state  or  transition.  Both  state  objects  and  transi¬ 
tion  objects  are  discussed  in  Section  A. 5.  The  class  functional  model  is  captured  by  the  process, 
datastore,  and  dataflow  Each  these  objects  are  discussed  in  detail  in  A. 6. 

A. 3.1  Attribute  Objects.  The  AST  for  the  GOMT  Attribute  object  is  shown  in  Figure  A.4. 
There  are  two  types  of  attributes  as  defined  by  Rumbaugh;  normal  and  derived.  Normal  attributes 
are  those  attributes  that  have  a  name  and  a  datatype  and  may  take  on  any  values  in  the  datatype. 
Unless  constrained  via  class-level  constraints,  these  attribute  values  are  generally  independent  of 
other  attribute  values.  Derived  attributes,  on  the  other  hand,  derive  their  value  from  values  of  the 
other  class  attributes.  Therefore,  there  are  two  subtypes  of  an  attribute  object:  derived-attr  and 
normal-attr.  Although  both  have  a  similar  structure-raame,  a  set  of  axioms,  and  a  datatype~the 
interpretation  of  that  structure  is  different.  Actually,  the  name  and  the  datatype  attributes  have 
the  same  interpretation.  It  is  in  the  set  of  axioms  where  the  difference  lies.  The  axioms  of  a  derived 
attribute  define  the  value  of  the  derived  attribute  based  on  other  class  attributes.  In  a  normal 
attribute,  the  axioms  define  only  the  initial  value  associated  with  the  attribute.  This  set  of  axioms 
may  be  a  single  value  such  as  “12.3”  or  it  may  be  a  complex  set  of  axioms  based  on  other  attribute 
values  set  during  object  initialization. 


Figure  A.4  GOMT  Attribute  Abstract  Syntax  Tree 
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A. 3. 2  Operation  Objects.  Figure  A.5  shows  the  AST  for  the  GOMT-Op  object.  An 
operation  object  can  fully  define  a  class  operation.  The  operation  signature  is  defined  by  the  name 
attribute,  parameter  subobjects,  and  the  result  subobject.  The  parameter  subobject  is  a  set  of 
parameter  objects  with  name  and  datatype  attributes.  The  result  subobject  defines  the  datatype 
returned  by  the  operation  (if  required).  The  definition  subobject  is  a  set  of  axiom  objects  that 
define  the  semantics  of  the  operation.  Finally,  is-abstract  is  a  boolean-valued  attribute  that  states 
whether  the  operation  is  fully  defined  or  not. 


Figure  A.5  GOMT  Operation  Abstract  Syntax  Tree 


A. 4  Association  Objects 

The  AST  for  an  Assoc  (association)  object  is  shown  in  Figure  A.6.  Every  association  has  a 
name  and  at  least  two  connections  (object  classes).  The  connection  object  is  the  same  as  defined 
above  in  Section  A.3  and  defines  the  classes,  roles,  qualifiers,  and  multiplicities  of  each  class  in  the 
association.  Associations  may  also  have  link  attributes  and  link  operations.  These  are  the  same 
attributes  and  operations  as  defined  in  Sections  A.3.1  and  A.3. 2. 
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Assoc- 


Figure  A.6  GOMT  Association  Abstract  Syntax  Tree 
A. 5  Dynamic  Model  Objects 

The  OMT  dynamic  model  captures  the  temporal  behavior  of  object  classes  defined  in  the 
object  model.  The  basic  concepts  of  the  dynamic  model  include  events,  actions,  and  states.  An 
event  is  a  one-way  transmission  from  one  object  to  another  and  may  pass  additional  information. 
An  action  is  an  operation  performed  by  an  object.  This  operation  may  modify  the  object  state 
or  generate  an  event.  A  state  is  defined  as  an  abstraction  of  attribute  values  of  an  object.  The 
dynamic  model  is  represented  using  state  charts  and  event  flow  diagrams.  A  statechart  models 
the  transitions  between  states  of  a  given  object  class.  In  the  dynamic  model,  these  transitions  are 
caused  by  the  reception  of  a  given  event  and  result  in  an  action  being  taken.  In  the  dynamic  model, 
OMT  allows  actions  to  occur  in  a  state  or  on  transitions  (i.e.,  a  combined  Mealy-Moore  machine); 
however,  to  simplify  the  translation  process  in  this  research,  I  have  restricted  the  dynamic  model 
to  a  Mealy  machine  representation  where  all  actions  occur  on  transitions.  This  does  not  represent 
a  semantic  restriction  since  the  equivalence  of  Mealy  and  Moore  machines  is  well  known  (47:44). 
Guards  (boolean  expressions)  may  be  added  to  transitions  to  prevent  them  from  occurring  unless 
certain  conditions  are  met.  If  the  guard  is  true  and  the  event  for  that  transition  is  received,  the 
transition  takes  place.  If  the  guard  is  false,  then  the  transition  does  not  take  place  even  though 
the  required  event  is  received. 

For  a  given  class,  the  dynamic  model  is  captured  as  a  set  of  states  and  transitions  between 
states.  The  ASTs  for  the  state  and  transition  objects  are  shown  in  Figures  A.7  and  A.8.  Each  state 
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object  has  a  name  attribute,  possibly  a  set  of  axiom  objects  defining  state  invariants,  and  a  set  of 
substate  objects.  Actually,  Rumbaugh  allows  two  special  types  of  states:  concurrent  and  substates. 
Concurrent  states  are  defined  implicitly  in  a  set  of  states.  Concurrent  states  are  partitions  of  a 
set  of  states  where  there  are  no  transitions  from  one  partition  to  the  other.  The  second  special 
type  of  state  is  a  substate.  Substates  are  a  set  of  states  that  further  define  transitions  while  within 
some  other,  higher-level  state.  Substates  are  defined  by  a  set  of  state  objects  internal  another  state. 
Thus  states  in  a  class  AST  are  arranged  hierarchically.  That  is,  the  state  objects  of  a  class  may 
not  contain  all  the  states  and  substates  for  the  class.  It  only  directly  contains  the  top-level  states. 
Each  substate  is  actually  stored  under  its  superstate  object. 


Figure  A. 7  GOMT  State  Abstract  Syntax  Tree 

While  states  are  stored  hierarchically,  transition  objects  are  stored  as  a  single  set  under  the 
class  object.  This  forces  all  states  in  a  class  to  have  unique  names.  A  transition  defines  an  arc  from 
one  state  to  another  based  on  the  receipt  of  an  event.  The  transition  name  attribute  is  the  name 
of  the  incoming  event  while  the  from-state  and  to-state  attributes  are  the  names  of  the  two  states 
involved.  Each  transition  may  have  parameters,  a  guard  condition,  and  a  set  of  actions  that  are 
performed  upon  receipt  of  the  named  event.  The  parameter  objects  are  a  sequence  of  parameters 
as  defined  in  Section  A. 3. 2,  the  guard  condition  is  defined  by  a  single  axiom,  and  the  actions  are  a 
sequence  of  action  objects  defining  the  actions  performed  by  the  object  upon  receipt  of  the  event. 
Each  action  object  has  a  name  attribute,  a  sequence  of  parameter  objects,  and  possibly  another 
action  object.  These  subaction  objects  are  only  used  when  its  parent  action  is  a  “send”  action.  A 
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“send”  action  is  the  OMT  syntax  for  broadcasting  an  event,  defined  in  the  subaction  object,  to  the 
system.  Subaction  objects  are  only  used  with  a  “send”  action. 


Figure  A.8  GOMT  Transition  Abstract  Syntax  Tree 

A. 6  Functional  Model  Objects 

In  OMT,  the  functional  model  is  represented  by  a  data  flow  diagram  that  shows  how  an 
aggregate-level  class  implements  functions  using  component  events  and  methods  within  the  aggre¬ 
gate.  Basically,  there  are  three  components  in  the  restricted  OMT  functional  model:  processes, 
data  flows,  and  data  stores.  Processes  translate  data  and  may  use  subprocesses  to  accomplish  their 
function.  Such  higher-level  processes  are  generally  decomposed  into  subprocesses  using  nested  data 
flow  diagrams.  Data  flows  show  how  data  is  passed  between  processes  and  datastores.  Besides 
passing  data  from  the  output  of  one  process  to  the  input  of  the  next  process,  data  flows  may  be 
(1)  duplicated  and  passed  to  many  processes,  (2)  decomposed  into  multiple  components,  or  (3) 
composed  from  a  number  of  components  into  a  single  aggregate  value.  Data  stores  are  passive 
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objects  that  store  data  for  later  use.  Obvious  data  stores  are  the  object  class  sets  and  associations. 
A  data  store  allows  a  process  to  create,  update,  and  store  data  for  later  use. 

The  ASTs  for  the  three  functional  components  are  shown  in  Figure  A.9.  The  process  and 
datastore  objects  are  very  similar.  Each  has  a  name  attribute  and  two  sets  of  flow  objects:  data- 
flows-in  and  data- flows- out.  A  flow  object  simply  stores  the  name  and  type  attributes  of  dataflow 
object  defined  below.  The  process  object  is  slightly  different  from  the  datastore  object  in  that 
the  process  object  may  also  have  subprocess  process  objects.  This  set  of  subprocesses  define  the 
implementation  of  the  process  as  defined  in  Section  5.5. 

The  third  functional  object  is  a  dataflow  object.  A  datafiow  object  has  four  attributes:  name, 
type,  source,  and  target.  The  name  of  the  dataflow  object  is  the  name  of  a  dataflow  arc  between 
two  entities  (processes  or  datastores)  in  the  functional  model  while  the  type  attribute  represents 
the  datatype  of  the  dataflow.  The  source  and  target  attributes  store  the  name  of  the  process  or 
datastore  where  the  dataflow  originates  and  terminates.  A  dataflow  with  a  blank  source  or  target 
attribute  denotes  an  off-page  connector.  In  the  case  of  a  top-level  dataflow,  an  off-page  connector 
represents  an  input  or  output  external  to  the  domain.  The  actual  source/target  of  an  off-page 
connector  in  a  nested  diagram  is  (or  at  least  should  be)  the  source/target  of  the  “parent”  dataflow 
from  the  parent  diagram. 


Figure  A.9  GOMT  Functional  Model  Abstract  Syntax  Tree 
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A.l  Generic  OMT  AST  Completeness 

This  section  discusses  the  completeness  of  the  GOMT  AST  in  terms  of  what  it  captures  and 
what  it  does  not.  Section  A. 7.1  discusses  the  completeness  of  the  GOMT  AST  in  terms  of  the 
OMT  object  model,  Section  A. 7.2  discusses  the  OMT  dynamic  model,  and  Section  A. 7.3  discusses 
the  OMT  functional  model. 

A.  7.1  Object  Model.  The  GOMT  AST  has  the  capability  to  capture  all  the  basic  features 
of  the  OMT  object  model.  The  GOMT  AST  directly  models  the  classes  (concrete  and  abstract), 
attributes  (normal  and  derived),  and  operations  (concrete  and  abstract).  The  GOMT  AST  also 
captures  the  relationships  defined  in  an  OMT  object  model  including  inheritance,  aggregation,  and 
association.  More  subtle  features  of  OMT  relationships  such  as  discriminators,  multiplicities,  and 
link  attributes  and  operations  are  also  captured. 

There  are  a  few,  non-critical,  OMT  object  model  items  not  directly  captured  by  the  GOMT 
AST.  The  first  of  these  is  operator  propagation;  however,  the  inability  to  directly  model  operator 
propagation  does  not  restrict  the  domain  designer  since  the  effect  of  operator  propagation  may 
be  explicitly  expressed  through  the  axiomatic  definition  of  the  operation.  Derived  classes  and 
associations  are  also  not  captured  in  the  GOMT  AST.  According  to  Rumbaugh  (83:75)  derived 
classes  and  associations  are  redundant  and  are  completely  determined  by  other  objects;  the  only 
reason  for  derived  classes  and  associations  is  to  aid  understandability.  Therefore,  since  the  lack 
of  derived  classes  and  associations  does  not  restrict  the  domain  designer’s  modeling  ability,  they 
are  not  included  in  the  GOMT  AST.  General  association  constraints  are  also  not  modeled  directly 
in  the  GOMT  AST;  however,  the  domain  designer  may  capture  these  constraints  as  class-level 
constraints  (via  first-order  axioms)  in  the  aggregate  containing  the  association. 

A. 7. 2  Dynamic  Model.  The  OMT  dynamic  model  consists  of  set  of  states  and  transitions 
based  on  a  Mealy-Moore  state  machine.  The  GOMT  AST  directly  captures  the  set  of  states  and 


transitions  between  them;  however,  while  the  OMT  dynamic  model  allows  states  to  have  internal 
activities  and  actions,  in  the  GOMT  AST,  I  assume  that  all  actions  occur  only  on  transitions 
(i.e.,  a  Mealy  state  machine).  However  a  Mealy  machine  (where  activities  and  actions  occur  only 
on  transitions)  has  been  shown  to  be  equivalent  in  expressive  power  to  a  Moore  machine  (where 
activities  and  actions  occur  in  a  state).  Thus  any  dynamic  model  captured  in  a  Mealy-Moore 
machine  is  translatable  to  a  Mealy  machine  and  may  be  captured  by  the  GOMT  AST.  The  OMT 
dynamic  model  also  allows  for  entry  and  exit  actions  that  are  performed  on  all  transitions  into  or 
out  of  a  state.  Although  entry  and  exit  actions  simplify  the  diagram,  they  are  easily  placed  on 
appropriate  incoming  and  outgoing  transition  with  the  same  affect. 

OMT  also  allows  for  substates  and  concurrent  states.  Substates  are  modeled  directly  in  the 
GOMT  AST.  Concurrent  states  are  not  explicitly  denoted  in  the  GOMT  AST;  however,  the  set  of 
concurrent  states  can  be  computed  by  partitioning  all  class  states  such  that  no  states  in  distinct 
partitions  share  a  transition.  Once  again,  although  not  captured  directly  in  the  GOMT  AST,  the 
set  of  concurrent  states  are  computable. 

Two  state  transition  features  allowed  in  the  OMT  dynamic  model  that  are  not  captured  di¬ 
rectly  in  the  GOMT  AST  are  control  splitting  and  synchronization.  In  essence,  control  splitting 
corresponds  to  transitioning  to  a  state  with  concurrent  substates,  as  shown  in  Figure  A.IO.  Syn¬ 
chronization  of  control  corresponds  to  leaving  a  set  of  states  after  two  or  more  events  occur  in  any 
order.  In  Figure  A.IO  eventl  causes  the  state  to  change  from  state  A  to  C,  or  more  correctly  to 
the  two  concurrent  states  Cl  and  C2.  When  events  event2  and  events  have  both  happened,  in  any 
order,  the  state  changes  to  state  B.  Without  special  split  and  synchronization  operators,  this  same 
control  mechanism  is  implemented  as  shown  in  Figure  A.ll.  The  attributes  synch2  and  synchS 
are  used  to  determine  when  event  2  or  3  has  been  received.  Then  two  separate  transitions  leave 
state  C  guarded  by  the  condition  that  the  appropriate  synchronization  attribute  has  been  set  to 
true.  Simple  enumeration  of  all  possible  combinations  of  state  and  synchronization  variable  values 
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Figure  A.  10  OMT  Split/Synchronization 


Figure  A.  11  Generic  OMT  Split/ Synchronization 

shows  that,  although  Figure  A.  10  is  more  aesthetically  pleasing,  both  Figures  A.  10  and  A.  11  have 
the  same  semantic  result.  Therefore,  although  the  GOMT  AST  does  not  include  transition  splits 
or  synchronizations,  their  effect  is  realizable  by  the  user. 

A. 1.3  Functional  Model.  The  OMT  functional  model  uses  data  flow  diagrams  consisting 
of  processes,  dataflows,  datastores,  actors,  and  control  flows.  Actors  and  control  flows  are  not 
directly  included  in  the  GOMT  AST.  A  functional  model  process  transforms  data  and  may  be 
further  refined  by  subprocesses.  Processes  and  subprocesses  are  stored  directly  in  the  GOMT  AST. 

Simple  dataflows  are  also  directly  stored  in  the  GOMT  AST;  however,  the  GOMT  AST 
does  not  capture  some  special  dataflow  notation  included  in  OMT  for  convenience:  duplication, 
composition,  and  decomposition.  Duplication  allows  the  output  of  one  process  to  flow  into  the 
inputs  of  two  or  more  processes.  Composition  takes  multiple  dataflows  and  composes  their  data  into 
an  aggregate  datatype.  Decomposition  accomplishes  the  inverse  of  composition-it  allows  aggregate 
datatypes  to  broken  into  it  component  datatypes.  Each  of  these  operations  can  be  modeled  with 
appropriately  defined  processes.  Therefore,  lack  of  direct  inclusion  in  the  GOMT  AST  does  not 
present  modeling  diflBculties. 
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According  to  Rumbaugh,  datastores  are  passive  objects  that  store  data  and  are  defined  in  the 
object  model.  Thus  datastores  are  classes  or  associations  and  are  directly  modeled  in  the  GOMT 
AST. 

Actors  are  active  objects  that  drive  OMT  functional  models  by  producing  and  consuming 
the  data  used  in  the  corresponding  datafiow  diagram.  However,  since  actors  represent  entities 
interacting  with  the  domain  being  modeled,  they  are  external  to  the  domain  and  are  not  required 
in  order  to  specify  the  domain  model.  Therefore,  actors  are  not  modeled  in  the  GOMT  AST. 

The  last  items  of  interest  in  the  OMT  dynamic  model  are  control  flows.  However,  according 
to  Rumbaugh,  control  flows  are  duplicative.  Therefore,  omitting  control  flows  from  the  GOMT 
AST  eliminates  a  source  of  inconsistency  and  does  not  restrict  the  domain  designer. 

A.  8  Conclusions 

This  Appendix  presents  the  generic  OMT  abstract  syntax  tree  definition  that  is  used  in  my 
research  as  the  starting  point  for  the  translation  from  OMT  to  my  theory-based  object  model. 
The  GOMT  captures  the  essential  details  of  OMT  based  on  assumptions  of  how  OMT  is  used. 
Because  OMT  has  a  rich  set  of  duplicative  features,  some  of  the  non-essential  features  are  not 
directly  modeled  in  the  GOMT  AST;  however,  OMT’s  modeling  power  has  not  been  decreased. 
Any  domain  modeled  in  Rumbaugh’s  OMT  representation  may  be  modeled  in  the  generic  OMT 
AST  without  semantic  compromise. 
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Appendix  B.  O- SLANG 


B.  1  Introduction 

This  Appendix  defines  the  syntax  and  semantics  of  the  algebraic  specification  language  O- 
Slang.  0-Slang  is  an  object-oriented  extension  of  Slang  (54)  and  like  Slang  incorporates 
category  theory  operations  directly  and  implicitly.  The  syntax  of  0-Slang  is  defined  by  the 
grammar  and  the  corresponding  0-Slang  AST  as  described  in  Section  B.3.  The  semantics  of 
0-Slang  is  defined  by  its  translation  to  Slang. 

B.2  Background 

0-Slang  is  an  extension  of  the  Slang  specification  language  used  in  Specware  (54,  55). 
Slang  is  based  on  first-order  logic  and  category  theory.  A  Slang  specification  is  a  theory  presen¬ 
tation  of  a  formal  theory.  Theories  consist  of  a  finite  set  of  sorts,  operations,  and  a  set  of  axioms 
closed  under  logical  entailment.  A  specification  is  a  set  of  sorts,  operations,  and  a  set  of  finite 
axioms.  Under  logical  entailment,  a  specification  generates  a  theory  that  includes,  as  axioms,  all 
theorems  that  can  be  generated  from  the  axioms  in  the  specification.  Specifications  and  specifica¬ 
tion  morphisms  define  the  cocomplete  category  Spec.  Diagrams  in  Spec  consist  of  specifications 
and  specification  morphisms  and  are  used  to  define  system  structure.  Slang  uses  the  category 
theory  colimit  operation  to  combine  smaller  specifications  into  larger,  more  complex  specifications. 

0-Slang  uses  the  concepts  from  Slang  to  capture  object-oriented  system  specifications. 
Sorts  and  operations  are  used  to  describe  various  internal  object  class  features  while  category 
theory  concepts  and  operations  are  used  to  define  the  relationships  between  object  classes. 

B.3  0-Slang  Syntax 

0-Slang  syntax  is  very  similar  to  the  core  SLANG  syntax  with  some  additional  language  con¬ 
structs.  The  Refine  0-Slang  AST  definition  and  grammar  are  shown  in  Section  B.3.1.  Whereas 


B-1 


core  Slang  has  only  specification  and  diagram  constructs  to  define  a  system,  0-Slang  has  numer¬ 
ous  object-oriented  constructs  that  map  into  specifications  and  diagrams.  Also,  0-Slang  hides 
much  of  the  diagram  construction  except  in  the  case  of  aggregation.  A  table  of  basic  0-Slang 
constructs  and  their  SLANG  counterparts  are  shown  in  Table  B.l. 


0-Slang 

Slang 

Class 

Diagram  &:  Specification 

Abstract-Class 

Diagram  &  Specification 

Event 

Specification 

Link 

Specification 

Association 

Diagram  &  Specification 

Aggregate 

Diagram 

Table  B.l  0-Slang  Constructs 


The  top  level  O- Slang  abstract  syntax  tree  is  shown  in  Figure  B.l.  Figure  B.l  defines 
an  0-Slang  Domain  Theory  as  consisting  of  one  or  more  0-Slang  specifications.  0-Slang 
specifications  represent  either  classes,  abstract  classes,  events,  links,  associations,  or  aggregates. 
Classes,  events,  links,  and  associations  are  all  similar  in  that  they  share  a  similar  specification 
body. 

Figure  B.2  shows  a  further  breakdown  of  classes,  events,  links,  and  associations.  Actually 
Figure  B.2  is  over  generalized.  While  classes  have  all  of  the  features  shown,  events,  links,  and 
associations  only  have  a  subset  of  those  as  shown  in  Figure  B.3. 

Figure  B.4  shows  the  abstract  syntax  tree  for  O-Slang  axioms.  Although  both  0-Slang 
and  Slang  are  based  on  first  order  logic,  their  axiom  syntax  is  different.  Slang  uses  a  hard  to 
read  “Lisp-like”  prefix  notation.  To  simplify  use,  0-Slang  uses  standard  infix  notation.  Although 
they  differ  in  appearance,  the  two  axiom  formats  are  semantically  equivalent. 


B.3.1  0-Slang  Grammar.  This  section  defines  the  0-Slang  grammar.  Words  in  bold 
typeface  indicate  language  key  words;  brackets  indicate  optional  items;  a  bar,  |,  represents  the 
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Figure  B.l  0-Slang  Abstract  Syntax  Tree  (Part  I) 


Figure  B.2  0-Slang  Abstract  Syntax  Tree  (Part  II) 
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Event 

Link 

Association 

Class  Sort 

Class  Sort 

Class  Sort 

Import 

Import 

Sort-Ref 

Sort-Ref 

Sort-Ref 

Operation 

Operation 

Attribute 

Attribute 

Method 

Method 

Event-Op 

Constructor 

Constructor 

Axiom 

Axiom 

Axiom 

Theorem 

Theorem 

Theorem 

Figure  B.3  0-Slang  Features  Sublist 


Figure  B.4  0-Slang  Abstract  Syntax  Tree  (Part  III) 


choice  operator;  and  the  *  and  +  operators  indicate  zero  or  one  or  more  of  the  preceding  items  are 
allowable. 


O-Slang-DomainTheory  — >  Spec^ 

Spec  —>  class  Class  \  abstract-class  AbClass  \  event  Event  \  link  Link 
I  association  Association  |  aggregate  Aggregate 

Class  Id  [  Parameter  [,  ParameterY  ]  is  ClassBody 

AbClass  — >  Id  [  Parameter  [,  Parameter]*  ]  ]  is  AbclassBody 
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Event  Id  [  Parameter  [,  Parameter]*  ]  ]  is  EventBody 


Link  — >  JtZ  [  Parameter  [,  Parameter]*  ]  ]  is  Link  Body 
Association  —y  Id  [  Parameter  [,  Porameter]*  ]  ]  is  AssocBody 
Aggregate  — +  Id  is  nodes  Aro(ie[,Aro<ie]*  arcs  Arc], Arc]*  end-aggregate 
Node  -^[Idi]  Id 

Arc  — >  Node  —  >  Node  [  :  {  NodeMap[,NodeMap]*  }  ] 

NodeMap  ^  Node  —  >  Node  |  (  OperationDecl  )  —  >  (  OperationDecl  )) 

Parameters  —*  Id  :  Id 

ClassBody  — >  class-sort  ClaasSort 
contained-class  Id[,Id\* 
imports  Id[,Id\* 
sorts  Id[,Id\* 

sort-axioms  SortAxiom\;,Sort Axiom]* 
operations  OperationBlock 
attributes  Attributes  lock 
state-attributes  State AttributeBlock 
methods  MethodBlock 
states  StateBlock 
events  EventBlock 
axioms  AxiomBlock 
theorems  TheoremBlock 
end-class 

AbClassBody  — ►  class-sort  ClaasSort 
contained-class  7d[,7d]* 
imports  Id[,Id]* 
sorts  Id[,I<I\* 

sort-axioms  Sort  Axiom  [,Sort  Axiom]  * 
operations  OperationBlock 
attributes  AttributeBlock 
state-attributes  StateAttributeBlock 
methods  MethodBlock 
states  StateBlock 
events  EventBlock 
axioms  AxiomBlock 
theorems  TheoremBlock 
end-class 
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EventBody  — >  class-sort  ClassSort 
imports  Id[,Id]* 
sorts  Id[Jd]* 

operations  OperationBlock 
attributes  AttributeBlock 
state-attributes  State  AttributeBlock 
methods  MethodBlock 
states  StateBlock 
events  EventBlock 
axioms  AxiomBlock 
theorems  TheoremBlock 
end-event 

LinkBody  — >  class-sort  ClassSort 
imports  Id[,Id\* 
sorts  Id[,Id]* 

operations  OperationBlock 
attributes  AttributeBlock 
state-attributes  State  AttributeBlock 
methods  MethodBlock 
states  StateBlock 
events  EventBlock 
axioms  AxiomBlock 
theorems  TheoremBlock 
end-link 

AssocBody  — +  class-sort  ClassSort 
link-class  LinkClass 
imports  Id[,Id\* 
sorts  Id[,Id]* 

sort-axioms  Sort Axiom[\Sort Axiom]* 
operations  OperationBlock 
attributes  AttributeBlock 
state-attributes  StateAttributeBlock 
methods  MethodBlock 
states  StateBlock 
events  EventBlock 
fixioms  AxiomBlock 
theorems  TheoremBlock 
end-association 

ClassSort  Id[,Id]*  <  Id[,Id]* 

SortAxiom  — ►  Id[=Id]* 
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OperationBlock  OperationDecV 


AttributeBlock  OperationDed* 

StateAttributeBlock  — »  OperationDed* 

MethodBlock  — ►  OperationDed* 

StateBlock  — »  OperationDed* 

EventBlock  OperationDed* 

Constructor  —*  constructors  {  Id  [,  id]*  }  construct  Id 
AxiomBlock  —>■  AxiomDef[;AxiomDef]* 

Axiom-Def  — >  Axiom  |  DefinitionBlock 
TheoremsBlock  — ♦  Axiom[,Axiom\* 

DefinitionBlock  definition  of  Id  is  Definition[,  Definition]*  end-definition 
OperationDed  — >  Id  :  OpSig 
OpSig  -4  Id], Id]*  -  >  Id], Id]* 

Axiom  — »  Relation  \  LogicTerm 
Relation  — +  SimpleAxiom  \  RelTerm 
Simple  Axiom  — >  Primary  |  MathTerm 

Primary  — ♦  Simpid  \  Tuple  \  Id  (  Axiom], Axiom]*  )  |  (  Axiom  )) 

Simpleld  -+  symbol 
Tuple  — *  <  Simpld'^'^  ,  > 

LogicTerm  — »  And-Term  ]  Or-Term  ]  Not-Term  ]  If f-Term 
I  Implies-Term  ]  Uquant-Term  |  Equant-Term 

And-Term  — »  Axiom  &  Relation 

Or-Term  — >  Axiom  ]  Relation 
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Not-Term 


Relation 


Iff- Term  — >  Axiom  <=>  Relation 

Implies-Term  — ►  Axiom  =>  Relation 

Uquant-Term  ^  V  (  Relation\,Relation\*  )  Relation 

Equant-Term  — >  3  (  Relation[, Relation]*  )  Relation 

RelTerm  -+  Equals-Term  \  NotEquals-Term  \  User-Term 
I  LT-Term  \  LT E-Term  \  GT-Term  |  GT E-Term 

Equals-Term  — >  Relation  =  SimpleAxiom 

NotEquals-Term  — >  Relation  <>  SimpleAxiom 

User- Term  — >  Relation  Id  SimpleAxiom 

LT-Term  — >  Relation  <  SimpleAxiom 

LTE-Term  -+  Relation  <=  SimpleAxiom 

GT-Term  — *  Relation  >  SimpleAxiom 

GTE-Term  — »  Relation  >=  SimpleAxiom 

MathTerm  -+  Add-Term  \  Sub-Term  \  Mult-Term  |  Div-Term 

Add-Term  — >  SimpleAxiom  -{-  Primary 

Sub-Term  — >  SimpleAxiom  —  Primary 

Mult-Term  -+  SimpleAxiom  *  Primary 

Div-Term  — >  SimpleAxiom  /  Primary 

Simpid  —>■  integer  \  real  \  Id 

Id  —y  [symbol  .  ]  symbol 
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B.4  0-Slang  Semantics 


The  semantics  of  0-Slang  specifications  are  defined  by  the  underlying  Slang  translations. 
Most  of  this  translation  is  straightforward.  Sorts  in  0-Slang  map  to  sorts  in  Slang;  operations, 
attributes,  methods,  events,  and  states  map  to  operations  in  Slang;  and  imports,  theorems,  axioms, 
and  definitions  in  0-Slang  map  to  identical  constructs  in  Slang.  More  complex  translations  are 
required  for  container  classes,  associations,  and  inherited  classes.  Actually,  the  container  classes 
and  associations  use  the  Slang  colimit  operation  and  Set  specification  to  build  sets  of  objects  as 
defined  in  Chapter  VII. 

B.4-1  Classes.  An  example  of  an  0-Slang  class  is  shown  Figure  B.5.  The  class  sort, 
sorts,  operations,  attributes,  state-attributes,  methods,  states,  and  events  define  the  signature  of  the 
underlying  Slang  specification  (Figure  B.6).  All  0-Slang  sorts,  including  the  class  sort,  become 
Slang  sorts  while  0-Slang  operations,  attributes,  state-attributes,  methods,  and  events  become 
Slang  operations.  0-Slang  states  map  to  Slang  constants,  or  nullary  operations.  Translation 
of  the  axioms  from  0-Slang  to  Slang  is  a  straight-forward  rewriting  exercise.  The  axioms  are 
translated  from  infix  notation  to  prefix  notation.  The  import  mechanism  works  identically  in  both 
0-SLANG  and  Slang  and  thus  no  translation  is  required.  The  sort  axiom  defined  in  Figure  B.5 
has  no  real  purpose  in  this  specification  except  to  illustrate  its  use.  The  0-Slang  sort  axiom  only 
allows  the  equivalencing  of  sorts  and  thus  is  a  subset  of  the  Slang  sort  axiom  construct. 

B.4.2  Class  Sets.  In  0-Slang,  whenever  a  class  is  defined,  a  “class  set”  class  is  automat¬ 
ically  created  as  shown  in  Figure  B.7.  Because  the  class  set,  denoted  by  a  contained-class  construct 
in  the  class  specification,  is  a  class  whose  class  sort  is  a  set  of  objects,  the  underlying  Slang  spec¬ 
ification  becomes  more  complicated.  Figure  B.8  shows  the  underlying  Slang  specifications  that 
are  generated  by  an  0-Slang  class  set  specification. 
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class  Acct  is 

import  Amnt,  Date 

class  sort  Acct 

sorts  Acct-State 

sort-axioms  Amnt  =  Integer 

operations 

attr-equal  :  Acct,  Acct  — »  Boolean 
attributes 

date  :  Acct  — »  Date 
bal  :  Acct  — »  Amnt 
state-attributes 

acct-state  :  Acct  —*  Acct-State 
methods 

create-acct  :  Date  Acct 
credit,  debit  :  Acct,  Amnt  — >  Acct 
states 

ok,  overdrawn  :  — »  Acct-State 
events 

new-acct  :  Date  — >  Acct 
deposit,  withdrawal  :  Acct,  Amnt  — ►  Acct 
axioms 

%  state  uniqueness  and  invariant  axioms 
ok  ^  overdrawn; 

V  (a:  Acct)  acct-state(a)  =  ok  ^  bal(a)  >  0; 

V  (a:  Acct)  acct-8tate(a)  =  overdrawn  ^  bal(a)  <  0; 

%  operation  definitions 

V  (a,al:  Acct)  attr-equal(a,  al)  =>■  date(a)  =  date(al)  A  bal(a)  =  bal(al); 

%  method  definitions 

V  (d:  Date)  date(create-acct(d))  =  d  A  bal(create-acct(d))  =  0; 

V  (a:  Acct,  x:  Amnt)  bal(credit(a,x))  =  bal(a)  -4-  x 

A  date(credit(a,x))  =  date(a)  A  rate(credit(a,x))  =  rate(a) 

A  int-date(credit(a,x))  =  int-date(a)  A  check-cost(credit(a,x))  =  check-co8t(a); 

%  event  definitions 

V  (d:  Date)  acct-8tat€(new-acct(d))=ok  A  attr-equal(new-acct(d),  create-acct{d)) 

V  (a:  Acct,  x:  Amnt)  acct-state(a)=ok 

acct-8tate(deposit(a,x))=ok  A  attr-equal(deposit(a,x),  credit(a,x)); 

V  (a:  Acct,  x:  Amnt)  acct-state(a)=soverdrawn  A  bal(a)  +  x  >  0 

^  acct-atate(deposit(a,x))=ok  A  attr-equal(dep08it(a,x),  credit(a,x)); 

V  (a:  Acct,  x:  Amnt)  acct-state(a)=overdrawn  A  bal(a)  +  x  <  0 

^  acct-8tate(dep08it(a,x))=overdrawn  A  attr«equal(dep08it(a,x),  credit(a,x)); 

V  (a:  Acct,  x:  Amnt)  acct-state(a)=ok  A  bal(a)  >  x 

^  acct*state(withdrawal(a,x))=:ok  A  attr-equal(withdrawal(a,x),  debit(a,x)); 

V  (a:  Acct,  x:  Amnt)  acct-8tate(a)=ok  A  bal(a)  <  x 

acct-8tate(withdrawal(a,x))=overdrawn  A  attr-equal(withdrawal(a,x),  debit{a,x)); 

V  (a:  Acct,  x:  Amnt)  acct-8tate(a)=overdrawn 

^  acct-state(withdrawal(a,x))=:overdrawn  A  attr-equal(withdrawal(a,x),  a) 
end-class 


Figure  B.5  Object  Class 


The  Acct-Class-Colimit  specification  creates  a  specification  with  a  set  of  Acct  objects.  The 
Acct-Class-Set  specification  simply  renames  the  set  to  Acct-Class.  This  renamed  specification  is 
then  included  into  the  Acct-Class  specification  where  the  class  operation  and  axioms  defined  in 
the  0-Slang  class  specification  are  translated  into  Slang  operations  and  axioms.  The  colimit 
and  renaming  specification  are  automatically  generated  based  on  the  class  name  specified  in  the 
contained- class  construct  on  the  0-Slang  specification. 


B.4.3  Communication.  An  example  of  an  0-Slang  event  theory  is  shown  in  Figure  B.9. 
This  is  translated  as  defined  above  for  a  class  into  a  Slang  specification  that  defines  a  theory 
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spec  Acct  is 

import  Amnt,  Date 
sorts  Acct,  Acct-State 
sort-axiom  Amnt  =  Integer 
op  attr-equal  :  Acct,  Acct  ->  Boolean 
op  date  :  Acct  ->  Date 
op  bal  :  Acct  ->  Amnt 
op  acct-state  :  Acct  ->  Acct-State 
op  create-acct  :  Date  ->  Acct 
op  credit,  debit  :  Acct,  Amnt  ->  Acct 
const  ok,  overdrawn  :  Acct-State 
op  new-acct  :  Date  ->  Acct 
op  deposit,  withdrawal  :  Acct,  Amnt  ->  Acct 
%  state  uniqueness  and  invariant  axioms 
axiom  (not  (equal  ok  overdrawn)) 

axiom  (fa  (a:  Acct)  (implies  (equal  (acct-state  a)  ok)  (greater-than-or-equal  (bal  a)  zero))) 
axiom  (fa  (a:  Acct)  (implies  (equal  (acct-state  a)  overdrawn)  (less-than  (bal  a)  zero))) 

%  operation  definitions 

axiom  (fa  (a  al:  Acct)  (implies  (attr-equal  a  al)  (and  (equal  (date  a)  (date  al))  (equal  (bal  a)  =  (bal  al)))) 

%  method  definitions 

axiom  (fa  (d:  Date)  (and  (equal  (date  (create-acct  d))  d)  (equal  (bal  (create-acct  d))  zero))) 
axiom  (fa  (a:  Acct  x:  Amnt)  (and  (and  (equal  (bal  (credit  a  x))  (plus  (bal  a)  x))  (date  (credit  a  x))  =  (date  a)) 
(and  (equal  (rate  (credit  a  x))  (rate  a)) 

(and  (equal  (int-date  (credit  a  x))  (int-date  a))  (equal  (check-cost  (credit  a  x))  (check-cost  a)))))) 

%  event  definitions 

axiom  (fa  (d:  Date)  (and  (equal  (acct-state  (new-acct  d))  ok)  (attr-equal  (new-acct  d)  (create-acct  d)))) 
axiom  (fa  (a:  Acct  x:  Amnt)  (implies  (equal  (acct-state  a)  ok) 

(and  (equal  (acct-state  (deposit  a  x))  ok)  (attr-equal  (deposit  a  x)  (credit  a  x))))) 
axiom  (fa  (a:  Acct  x:  Amnt)  (implies  (and  (equal  (acct-state  a)  overdrawn) 

(greater-than-or-equal  (plus  (bal  a)  x)  zero)) 

(and  (equal  (acct-state  (deposit  a  x))  ok)  (attr-equal  (deposit  a  x)  (credit  a  x))))) 
axiom  (fa  (a:  Acct  x:  Amnt)  (implies  (and  (equal  (acct-state  a)  overdrawn)  (less-than  (plus  (bal  a)  x)  zero)) 
(and  (equal  (acct-state  (deposit  a  x))  overdrawn)  (attr-equal  (deposit  a  x)  (credit  a  x))))) 
axiom  (fa  (a:  Acct  x:  Amnt)  (implies  (and  (equal  (acct-state  a)  ok)  (greater-than-or-equal  (bal  a)  x)) 

(and  (equal  (acct-state  (withdrawal  a  x))  ok)  (attr-equal  (withdrawal  a  x)  (debit  a  x))))) 
axiom  (fa  (a:  Acct  x:  Amnt)  (implies  (and  (equal  (acct-state  a)  ok)  (less-than  (bal  a)  x)) 

(and  (equal  (acct-state  (withdrawal  a  x))  overdrawn)  (attr-equal  (withdrawal  a  x)  (debit  a  x))))) 
axiom  (fa  (a:  Acct  x:  Amnt)  (implies  (equal  (acct-state  a)  overdrawn) 

(and  (equal  (acct-state  (withdrawal  a  x))  overdrawn)  (attr-equal  (withdrawal  a  x)  a)))) 
end-spec 

Figure  B.6  Underlying  Slang  Specification 


signature.  This  signature  is  used  in  a  colimit  operation  (via  an  aggregate  definition)  to  unify  an 
event  in  one  class  with  an  event  in  a  second  class. 


B.4-4  Links.  A  link  is  used  to  define  a  general  relationship  between  two  classes.  An 
example  of  an  0-Slang  link  is  shown  in  Figure  B.IO  with  the  Slang  equivalent  specification  shown 
in  Figure  B.ll.  Because  a  link  is  created  without  knowing  the  actual  classes  it  is  associating,  the 
sorts  X  and  Y  do  not  have  meaning  until  they  are  unified  with  a  class  sort  in  the  aggregate  colimit. 
All  sorts  and  operations  are  translated  exactly  like  those  of  a  class  as  described  in  Section  B.4.1. 

B.4.5  Associations.  An  association  is  a  set  of  links  and  thus  has  a  very  similar  translation 
to  that  of  a  class  set.  However,  instead  of  using  just  the  class  specifications  related  through  the 
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class  Acct-Class  is 
contained-class  ACCT 
class  sort  Acct-Class 
events 

new-acct-class  :  — ►  Acct-Class 
withdrawal  :  Acct-Class,  Amnt  — ►  Acct-Class 
deposit  :  Acct-Class,  Amnt  — ►  Acct-Class 
axioms 

new-acct-class()  =  empty-set; 

V  (a:  Acct,  ac:  Acct-Class,  x:  Amnt)  a  €  ac  O  deposit(a,x)  6  deposit(ac,x); 

V  (a:  Acct,  ac:  Acct-Class,  x:  Amnt)  a  €  ac  withdrawal(a,x)  6  withdrawal(ac,x) 

end-class 


Figure  B.7  0-Slang  Class  Set  Specification 


spec  Acct-Class-Colimit  is 
colimit  of  diagram 

nodes  TRIV,  ACCT,  SET 

arcs  TRIV  ->  ACCT  :  {E  ->  Acct} 

TRIV  ->  SET  :  {} 
end-diagram 

spec  Acct-Class-Set  is 

translate  ACCT-CLASS-COLIMIT 
by  {Set  ->  Acct-Class,  E  ->  Acct} 

spec  Acct-Class  is 

import  ACCT-CLASS-SET 
op  new-acct-class  ;  ->  Acct-Class 
op  withdrawal  ;  Acct-Class,  Amnt  ->  Acct-Class 
op  deposit  ;  Acct-Class,  Amnt  ->  Acct-Class 
axiom  (equal  (new-acct-class)  empty-set) 

axiom  (fa  (a;  Acct  ac;  Acct-Class  x:  Amnt)  (iff  (in  a  ac)  (in  (deposit  a  x)  (deposit  ac,x)))) 
axiom  (fa  (a;  Acct  ac;  Acct-Class  x;  Amnt)  (iff  (in  a  ac)  (in  (withdrawal  a  x)  (withdrawal  ac  x)))) 
end-spec 

Figure  B.8  Slang  Class  Set  Specification 


link  specification,  the  sets  of  the  related  classes  must  be  used  to  allow  for  various  OMT  association 
multiplicities  (optional,  many,  ordered,  etc.).  This  does  not  present  a  problem  since  every  class 
has  an  associated  class  set  specification  already  defined.  An  example  of  an  0-Slang  association 
is  shown  in  Figure  B.12  with  its  Slang  counterparts  shown  in  Figure  B.13. 


B.4.6  Aggregates.  Aggregates  are  a  unique  type  of  0-Slang  specification.  Aggregates 
define  a  colimit  operation  over  previously  defined  classes,  associations,  and  events  that  make  up 
the  aggregate  specification.  An  aggregate  specification  does  not  have  the  ability  to  add  attributes. 


event  Event  is 
class  sort  Event-Sort 
sorts  X,  Y 
events 

event  :  Event-Sort,  X,  Y  -+  Event-Sort 

end-class 

Figure  B.9  Event  Theory 
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link  XY-Link  is 
class  sort  XY-Link 
sorts  X,  Y 
operations 

attr-equal  :  XY-Link,  XY-Link  — ♦  Boolean 
attributes 

x-obj  :  XY-Link  -+  X 

y-obj  :  XY-Link  Y 
methods 

create-xy-link  :  X,  Y  — *  XY-Link 
events 

new-xy-Iink  :  X,  Y  -+  XY-Link 

axioms 

%  operation  definition 

V  (xl,x2:  X)  attr-equal(xl,x2)  O  x-obj{xl)  =  x-obj(x2)  A  y-obj(xl)  =  y-obj(x2); 

%  create  method  definition 

V  (x:  X,  y:  Y)  x-obj(create-xy-link(x,y))  =  x  A  y-obj(create-xy-link(x,y))  =  y; 

%  new  event  definition 

V  (x:  X,  y:  Y)  attr-equal(new-xy-link(x,y),  create-xy-link(x,y)) 
end-link 


Figure  B.IO  0-Slang  Link  Specification 


spec  XY-Link  is 

sorts  X,  Y,  XY-Link 

op  attr-equal  :  XY-Link,  XY-Link  ->  Booiean 
op  x-obj  ;  XY-Link  ->  X 
op  y-obj  ;  XY-Link  ->  Y 
op  create-xy-iink  :  X,  Y  ->  XY-Link 
op  new-xy-iink  :  X,  Y  ->  XY-Link 

axiom  (fa  (xl:X  x2;X)  (iff  (attr-equal  xl  x2)  (and  (equal  (x-obj  xl)  (x-obj  x2))  (equal  (y-obj  xl)  (y-obj  x2))))) 
axiom  (fa  (x:X  y;Y)  (and  (equal  (x-obj  (create-xy-link  x  y))  x)  (equal  (y-obj  (create-xy-link  x  y))))) 
axiom  (fa  (x;X  y;Y)  (attr-equal  (new-xy-iink  x  y)  (create-xy-link  x  y))) 
end-spec 


Figure  B.ll  Slang  Link  Specification 


methods,  events,  constraints,  etc.  These  additions  are  made  through  an  extension  of  the  aggregate 
specification  using  a  class  specification  that  imports  the  aggregate.  The  nodes  of  an  aggregate  are 
the  classes,  associations,  and  events  included  in  the  aggregate  while  the  arcs  are  the  specification 
morphisms  between  the  nodes  that  define  the  relationships  between  the  nodes.  Besides  simply 
combining  a  number  of  class  and  association  specifications  into  a  single  aggregate  specification,  the 
colimit  operation  unifies  sorts  and  operations  defined  in  separate  classes  and  associations. 

An  example  of  an  0-Slang  aggregate  is  shown  in  Figure  B.14.  The  diagram  of  the  aggregate 
is  shown  in  Figure  B.15.  The  Slang  version  of  the  aggregate  is  shown  in  Figure  B.16. 

Once  the  colimit  specification  is  specified,  new  operations  and  axioms  are  added  to  an  exten¬ 
sion  of  colimit  specification.  This  extension  is  created  by  importing  the  colimit  specification  into  a 
class  specification  and  adding  new  operations  and  axioms  as  defined  in  Section  B.4.1. 
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association  XY-Assoc  is 
link-cleuss  XY-Link 
class  sort  XY-Assoc 
sorts  X-Set,  Y-Set 
methods 

image  ;  XY-Assoc,  Y  — ►  X-Set 

image  :  XY-Assoc,  X  — ►  Y-Set 
events 

new-xy-assoc  :  — »  XY-Assoc 
axioms 

%  multiplicity  axioms 

V  (1:  XY-Assoc,  y:  Y)  8ize(image(l,  y))  >  1; 

V  (1:  XY-Assoc,  x:  X)  size(image(l,  x))  =  1; 

%  new  event  definition 

new-xy-assoc()  =  empty-set; 

%  image  definitions 

V  (xy:XY-Assoc,  1:XY-Link,  y:Y)  (1  G  xy  &  y-obj(l)  =  y)  =>■  x-obj(l)  €  image(xy,y); 

V  (xy:XY- Assoc,  1:XY-Link,  x:X)  (1  G  xy  &:  x-obj(l)  =  x)  =>•  y-obj(l)  G  image(xy,x) 

end-association 


Figure  B.12  0-Slang  Association  Specification 


spec  XY-Assoc-Colimit  is 
colimit  of  diagram 

nodes  TRIV,  XY-LINK,  SET 

arcs  TRIV  ->  XY-LINK  :  {E  ->  XY-Link} 

TRIV  ->  SET  :  {} 
end-diagram 

spec  XY-Assoc-Set  is 

translate  XY-ASSOC-COLIMIT 
by  {Set  ->  XY-Assoc,  E  ->  XY-Link} 

spec  XY-Assoc  is 

import  XY-ASSOC-SET,  X-CLASS,  Y-CLASS 
op  image  ;  XY-Assoc,  Y  — *  X-Class 
op  image  ;  XY-Assoc,  X  — >  Y-Class 
op  new-xy-assoc  ;  — •  XY-Assoc 

axiom  (fa  (l;XY-Assoc  y;Y)  (greater-than-or-equal  (size  (image  1  y))  one)) 
axiom  (fa  (l:XY-Assoc  x;X)  (equal  (size  (image  1  x))  one)) 
axiom  (equal  (new-xy-assoc)  empty-set) 

axiom  (fa  (xy;XY-Assoc  1;XY-Link  y:Y)  (iff  (and  (in  I  xy)  (equal  (y-obj  1)  y))  (in  (x-obj  1)  (image  xy  y)))) 
axiom  (fa  (xy;XY-Assoc  1;XY-Link  x:X)  (iff  (and  (in  I  xy)  (equal  (x-obj  l)  x))  (in  (y-obj  l)  (image  xy  x)))) 
end-spec 

Figure  B.13  Slang  Association  Specification 


B.4-7  Inheritance.  To  this  point,  translation  of  0-Slang  specifications  to  Slang  speci¬ 
fications  is  relatively  simple;  however,  inheritance  is  more  complex.  Because  Slang  has  a  limited 
subsorting  feature  and  makes  no  allowance  for  multiple  subsorting,  subsorting,  as  defined  in  O- 
Slang,  is  simulated  in  Slang.  This  simulation  requires  defining  a  subsort  predicate  based  on  the 
defined  attributes  and  copying  each  superclass  attribute  and  operation  into  each  subclass. 


B. 4.7.1  Single  Inheritance.  A  typical  example  of  0-Slang  single  inheritance  is 
shown  in  Figures  B.17  and  B.18.  Person  is  the  supersort  and  Student  is  a  subsort  of  Person.  The 
Student  class  defines  only  one  new  attribute,  GPA.  (For  simplicity,  no  events  have  been  defined  for 
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aggregate  XY-Aggregate  is 

nodes  INTEGER,  SET-1:  SET,  SET-2:  SET,  SET-3:  SET, 
X-CLASS,  Y-CLASS,  XY-Assoc 
arcs  SET-1  -»  X-CLASS  :  {E  -►  X,  SET  -*  X-CIass}, 

SET-1  XY-Assoc  :  {E  —  X  SET  -►  X-Class}, 

5  SET-2  -»  Y-CLASS  :  {E  -►  Y,  SET  Y-Class}, 

SET-2  -►  XY-Assoc  :  {E  ->  Y,  SET  -►  Y-Class}, 

SET-3  -►  XY-Assoc  :  {E  —  XY-Link,  SET  -►  XY-Assoc}, 
INTEGER  -*  SET-1  :  {}, 

INTEGER  SET-2  :  O 
INTEGER  -►  SET-3  :  {} 
end-aggregate 

Figure  B.14  0-Slang  Aggregation  Specification 


XY-Aggregate 


Figure  B.15  Aggregation  Composition 


spec  XY-Aggregate  is 
coiimit  of  diagram 

nodes  INTEGER,  SET-1:  SET,  SET-2:  SET,  SET-3:  SET, 
X-CLASS,  Y-CLASS,  XY-Assoc 
arcs  SET-1  X-CLASS  :  {E  —  X}, 

SET-1  -►  XY-Assoc  :  {E  -►  X}, 

SET-1  —  X-CLASS  :  {SET  -*  X-Class}, 

SET-1  XY-Assoc  :  {SET  —*■  X-Class}, 

SET-2  -»  Y-CLASS  :  {E  —  Y}, 

SET-2  ->  XY-Assoc  :  {E  —  Y}, 

SET-2  Y-CLASS  :  {SET  —  Y-Class}, 

SET-2  -»  XY-Assoc  :  {SET  ^  Y-Class}, 

SET-3  -►  XY-Assoc  :  {E  XY-Link,  SET  -»  XY-Assoc}, 
INTEGER  -»  SET-1  :  {}, 

INTEGER  —  SET-2  :  {}, 

INTEGER  -+  SET-3  :  {} 
end-diagram 

Figure  B.16  Slang  Aggregation  Specification 
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the  Person,  Student,  or  Faculty  classes  defined  below  or  in  their  Slang  counterparts.  These  would 
be  defined  as  usual  and  translated  the  same  as  the  methods  shown  below.) 


class  Person  is 
import  Date}  Sex 
class  sort  Person 
attributes 

name  :  Person  —*■  String 
birthday  :  Person  —*  Date 
ssan  :  Person  — ►  Integer 
sex  :  Person  — ♦  Sexuality 
methods 

create-person  :  String  — »  Person 
change-name  :  Person,  String  —*■  Person 
events 
axioms 

ssan(p)  >  0; 

%  create-person 
name(create-person(n))  =  n; 
birthday(create-person(n))  =:  default-date; 
ssan(create-person(n))  =  0; 
8ex(create-person(n))  =  male; 

%  change-name 
name(change-name(p,n))  =  n; 
birthday(change-name(p,n))  =  birthday(p); 
ssan(change-name(p,n))  =  ssan(p); 
sex(change-name(p,n))  =  sex(p) 
end-class 


Figure  B.17  0-Slang  Person  Superclass 


class  Student  is 
import  Person,  Gpa 
class  sort  Student  <  Person 
attributes 

gpa  :  Student  Gpa 
methods 

create-student  :  String  — ►  Student 
axioms 

%  create-student 

name(create-8tudent(n))  =  name(create-person(n)); 
birthday(create-8tudent(n))  =  birthday(create-per8on(n)); 
ssan(create-student(n))  =  8san(create-per8on(n)); 
8€x(create-student(n))  =  sex(create-person(n)); 
gpa(create-8tudent(n))  =  0 
end-class 


Figure  B.18  0-Slang  Student  Subclass 


Inheritance,  as  defined  in  Section  4.4,  requires  that  (1)  all  objects  of  a  subclass  be  objects  of 
each  of  its  superclasses,  (2)  that  all  operations  defined  on  a  superclass  are  defined  on  the  subclass, 
and  (3)  that  the  semantics  of  those  operations  are  identical  on  attributes  defined  in  the  superclass. 
In  Slang,  subsorting  is  accomplished  via  sort  axioms  as  shown  below. 

sort-axiom  subsort  —  supersort  |  predicate 
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The  sort  axiom  states  that  the  subsort  consists  of  all  values  from  the  supersort  where  the  predicate 
is  true.  Thus,  given  the  right  predicate  definition,  Slang  sort  axioms  can  directly  define  simple 
inheritance.  Figures  B.19  and  B.20  show  the  Slang  translations  of  the  Person  and  Student  classes 
defined  above. 


spec  PERSON  is 
import  DATE,  SEX 
sort  Person,  String 
op  name  :  Person  —  >  String 
op  birthday  :  Person  —  >  date 
op  ssan  :  Person  —  >  Integer 
op  sex  :  Person  —  >  Sexuality 
op  create-person  :  String  —  >  Person 
op  change-name  :  Person,  String  —  >  Person 
axiom  (greater-than  (ssan  p)  zero) 
axiom  (equal  (name  (create-person  n))  n) 
axiom  (equal  (birthday  (create-person  n))  default-date) 
axiom  (equal  (ssan  (create-person  n))  zero) 
axiom  (equal  (sex  (create-person  n))  male) 
axiom  (equal  (name  (change-name  p  n))  n) 
axiom  (equal  (birthday  (change-name  p  n))  (birthday  p)) 
axiom  (equal  (ssan  (change-name  p  n))  (ssan  p)) 
axiom  (equal  (sex  (change-name  p  n))  (sex  p)) 
end-spec 

Figure  B.19  Slang  Person  Superclass 


The  Person  class  translates  to  Slang  as  described  in  Section  B.4.1.  It  is  in  the  Student  class 
that  the  inheritance  simulation  takes  place.  Because  Slang  is  very  strongly  typed,  an  operation 
defined  on  a  supersort  is  not  automatically  defined  on  its  subsorts.  Slang  does  provide  a  built-in 
inclusion  function,  relax,  that  maps  elements  of  the  subsort  to  their  corresponding  elements  of  the 
supersort.  Thus  the  axiom 

(equal  (name  s)  (name  ((relax  student?)  s))) 
or, 

name{s)  =  name{relax{studentl){s)) 

states  the  name  of  a  student,  s,  is  equal  to  the  name  of  an  equivalent  person  in  the  supersort 
denoted  by  ((relax  student?)  s).  Thus  the  relax  operator  maps  s  from  the  student  subsort  to  the 
Person  supersort  by  relaxing  the  student?  predicate.  Therefore,  for  each  operation  defined  in  the 
Person  class,  an  equivalent  operation  must  be  defined  on  the  Student  class.  Axioms  are  used  (as 
shown  above)  to  ensure  that  the  semantics  of  the  operations  on  superclass  attributes  are  equivalent. 
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spec  STUDENT  is 
import  PERSON 
sort  Student,  Gpa 

sort-axiom  Student  =  Person  |  student? 

op  name  :  Student  —  >  String 

op  birthday  :  Student  —  >  Date 

op  ssan  ;  Student  —  >  Integer 

op  sex  ;  Student  —  >  Sexuality 

op  gpa  ;  Student  —  >  Gpa 

op  create-student  :  String  —  >  Student 

op  change-name  :  Student,  String  —  >  Student 

op  student?  ;  Person  —  >  Boolean 

axiom  (fa  {p;person  s:student) 

(implies  (equal  p  ((relax  student?)  s)) 

(equal  (student?  p) 

(ex  (r:gpa)  (equal  (gpa  s)  r))))) 
axiom  (equal  (name  s)  (name  ((relax  student?)  s))) 
axiom  (equal  (birthday  s)  (birthday  ((relax  student?)  s))) 
axiom  (equal  (ssan  s)  (ssan  ((relax  student?)  s))) 
axiom  (equal  (sex  s)  (sex  ((relax  student?)  s))) 
axiom  (equal  (name  (create-student  n))  (name  (create-person  n))) 
axiom  (equal  (birthday  (create-student  n)) 

(birthday  (create-person  n))) 

axiom  (equal  (ssan  (create-student  n))  (ssan  (create-person  n))) 
axiom  (equal  (sex  (create-student  n))  (sex  (create-person  n))) 
axiom  (equal  (gpa  (create-student  n))  zero) 
axiom  (equal  (name  (change-name  s  n)) 

(name  (change-name  ((relax  student?)  s)  n))) 
axiom  (equal  (birthday  (change-name  s  n)) 

(birthday  (change-name  ((relax  student?)  s)  n))) 
axiom  (equal  (ssan  (change-name  s  n)) 

(ssan  (change-name  ((relax  student?)  s)  n))) 
axiom  (equal  (sex  (change-name  s  n)) 

(sex  (change-name  ((relax  student?)  s)  n))) 
axiom  (equal  (gpa  (change-name  s  n))  (gpa  s)) 
end-spec 


Figure  B.20  SLANG  Student  Subclass 


The  predicate  student?  is  defined  by  the  signature  and  axiom  shown  below. 

op  student?  :  Person  -  >  Boolean 
axiom  (fa  (piperson  srstudent) 

(implies  (equal  p  ((relax  student?)  s)) 

(equal  (student?  p) 

(ex  (r:gpa)  (equal  (gpa  s)  r))))) 

In  conventional  notation  this  would  be  as  follows. 

V  (prperson  s:student)  p  =  relax(student?)(s) 

student?(p)  =  (3  (r:gpa)  gpa(s)  =  r) 

Basically,  the  student?  predicate  states  that  for  an  object  to  be  in  the  Student  class,  the  attribute, 
gpa,  must  be  defined  on  that  object.  In  general,  the  subclass  predicate  is  defined  by  requiring 
all  attributes  of  the  class  to  be  defined  on  its  objects.  Thus  Slang  allows  us  to  determine  if  an 
element  of  the  supersort  is  a  member  of  a  subsort  and  to  create  an  element  of  the  supersort  from 
elements  in  the  subsort;  unfortunately,  it  does  not  provide  a  simple  or  elegant  way  to  accomplish 
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these  operations.  Therefore,  when  translating  a  subclass  definition,  not  only  must  the  superclass 
specification  be  imported,  but  an  operation  for  each  operation  in  the  superclass  must  be  created 
and  explicitly  defined  as  equivalent  to  the  superclass  operation  acting  on  a  relaxed  subsort  element. 


The  translation  of  0-Slang  single  inheritance  satisfies  the  three  requirements  for  inheritance 
described  above.  First,  because  Slang  supports  simple  subsorting,  all  objects  of  a  subclass  are 
objects  of  each  of  its  superclasses,  even  though  use  of  the  relax  operation  is  required.  Second, 
all  operations  of  the  superclass  sort  are  defined  on  the  subsort  since  they  are  explicitly  redefined 
(using  the  same  names  and  parameters)  on  the  subclass  objects.  Finally,  the  semantics  of  superclass 
operations  are  identical  on  attributes  defined  in  the  superclass  since  the  subclass  operations  are 
equivalenced  to  the  superclass  operations  over  the  superclass  attributes.  Therefore,  the  translation 
described  above  fully  specifies  the  semantics  of  0-Slang  single  inheritance. 


B. 4-7.2  Multiple  Inheritance.  Now  that  I  have  defined  the  0-Slang  to  Slang 
translation  for  single  inheritance,  I  extend  this  translation  to  multiple  inheritance.  Unfortunately, 
this  extension  is  not  straightforward.  Slang  does  not  allow  a  sort  to  be  a  subsort  of  more  than 
one  supersort;  therefore,  this  requirement  must  be  simulated.  The  requirements  that  all  superclass 
operations  be  defined  on  the  subclass  and  that  the  semantics  of  the  operations  are  equivalent  over 
superclass  attributes  are  translated  the  same  way  as  for  single  inheritance.  To  set  up  an  example, 
assume  a  Faculty  class  is  defined  as  a  subclass  of  Person  as  shown  in  Figure  B.21  and  B.22. 


class  Faculty  is  <  Person 
import  Person,  Academic-Rank 
class  sort  Faculty 
attributes 

academic-rank  :  Faculty  —*■  Academic-Rank 
methods 

create-faculty  :  String  — *  Faculty 
axioms 

%  create-faculty 

name(create-faculty(n))  =  name(create-person(n)); 
birthday(create-faculty(n))  =  birthday(create-person(n)); 
ssan(create-faculty(n))  =  88an(create-per8on(n)); 
sex(create-faculty(n))  =  8ex(create-person(n)); 
academic-rank(create-faculty(n))  =  instructor 
end-class 

Figure  B.21  0-Slang  Faculty  Subclass 
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spec  FACULTY  is 

import  PERSON,  ACADEMIC-RANK 
sort  Faculty 

sort-£txiom  Faculty  =  Person  |  faculty? 

op  name  ;  Faculty  —  >  String 

op  birthday  ;  Faculty  —  >  Date 

op  ssan  ;  Faculty  —  >  Integer 

op  sex  ;  Faculty  —  >  Sexuality 

op  academic-rank  ;  Faculty  —  >  Academic-Rank 

op  create-faculty  ;  String  —  >  Faculty 

op  change-name  ;  Faculty,  String  —  >  Faculty 

op  faculty?  ;  Person  —  >  Boolean 

axiom  (fa  (p;person  ffaculty) 

(implies  (equal  p  ((relax  faculty?)  f)) 

(equal  (faculty?  p) 

(ex  (r:Academic-Rank)  (equal  (academic-rank  f)  r))))) 
axiom  (equal  (name  f)  (name  ((relax  faculty?)  f))) 
axiom  (equal  (birthday  f)  (birthday  ((relax  faculty?)  f))) 
axiom  (equal  (ssan  f)  (ssan  ((relax  faculty?)  f))) 
axiom  (equal  (sex  f)  (sex  ((relax  faculty?)  f))) 
axiom  (equal  (name  (create-faculty  n))  (name  (create-person  n))) 
axiom  (equal  (birthday  (create-faculty  n)) 

(birthday  (create-person  n))) 

axiom  (equal  (ssan  (create-faculty  n))  (ssan  (create-person  n))) 
axiom  (equal  (sex  (create-faculty  n))  (sex  (create-person  n))) 
axiom  (equal  (academic-rank  (create-faculty  n))  instructor) 
axiom  (equal  (name  (change-name  f  n)) 

(name  (change-name  ((relax  faculty?)  f)  n))) 
axiom  (equal  (birthday  (change-name  f  n)) 

(birthday  (change-name  ((relax  faculty?)  f)  n))) 
axiom  (equal  (ssan  (change-name  f  n)) 

(ssan  (change-name  ((relax  faculty?)  f)  n))) 
axiom  (equal  (sex  (change-name  f  n)) 

(sex  (change-name  ((relax  faculty?)  f)  n))) 
axiom  (equal  (academic-rank  (change-name  f  n))  (academic-rank  f)) 
end-spec 


Figure  B.22  Slang  Faculty  Subclass 


What  is  desired  is  to  create  a  teaching  assistant  class,  TA,  that  is  a  subclass  of  both  the 
Student  class  and  the  Faculty  class.  The  0-Slang  for  such  a  class  is  shown  in  Figure  B.23.  By 
importing  both  Student  and  Faculty  classes  and  requiring  that  the  TA  class  sort  be  a  subsort  of 
both  the  Student  and  Faculty  class  sorts,  multiple  inheritance  is  achieved.  The  operations  have  been 
imported  and  defined  over  both  Student  and  Faculty,  and  thus  are  automatically  defined  over  TA 
objects  since  the  TA  objects  are  a  subset  of  both  the  Student  and  Faculty  objects.  A  new  operation, 
create-ta,  is  defined  in  accordance  with  the  appropriate  Student  and  Faculty  create  operations. 

The  translation  of  TA  to  Slang  is  not  quite  as  simple  as  for  single  inheritance.  As  defined 
in  the  theory-based  object  model  in  Chapter  VII,  multiple  inheritance  is  defined  by  the  colimit  of 
the  superclass  specifications  (with  the  shared  part  defined  by  common  superclasses  and  any  shared 
data  type  specifications).  Since  both  Student  and  Faculty  are  subclasses  of  the  Person  class,  the 
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class  TA  is 

Student,  Faculty 

class  sort  TA  <  Student,  Faculty 
methods 

create-ta  :  String  — *  TA 
axioms 
%  create-ta 

name(create-ta(n))  =  name(create-person{n)); 
birthday(create-ta(n))  =  birthday(create-per8on(n)); 
ssan(create-ta(n))  =  ssan(create-person(n)); 
sex(create-ta(n))  =  8ex(create-per8on(n)); 
gpa(create-ta(n))  =  gpa(create-8tudent(n)); 

academic-rank(create-ta(n))  =  academic-rank(create-faculty(n)) 
end'class 

Figure  B.23  0-Slang  TA  Subclass 


diagram  consisting  of  Person,  Student,  and  Faculty  (and  the  appropriate  morphisms  between  them) 
defines  the  colimit  specification  used  to  create  the  TA  specification  (Figure  B.24). 

Once  the  colimit  specification  has  been  created,  it  is  imported  into  the  TA  Slang  specification 
where  it  is  extended  by  adding  the  class  sort,  TA,  and  constructing  the  subsort  equivalences. 
Because  Slang  only  supports  a  single  subsort  definition,  the  TA  sort  must  be  defined  to  be  a 
subsort  of  the  lowest  common  supersort  of  all  of  the  superclasses  used  to  define  the  subclass.  In 
this  example,  since  Student  and  Faculty  are  both  subclasses  of  Person,  TA  is  defined  to  be  a  subclass 
of  Person  as  well.  If  some  of  the  superclasses  are  not  descendants  of  a  common  superclass,  the 
object-class  sort  (the  sort  which  includes  all  object  names)  is  used.  This  situation  is  not  discussed 
further  except  to  state  that  all  object  class  sorts  are,  by  definition,  subsorts  of  the  object-class  sort. 

The  fact  that  TA  is  a  subsort  of  both  Person  and  Faculty  classes  is  captured  by  the  definition 
of  a  subsort  predicate  ta?  as  defined  below. 

axiom  (fa  (t:ta)  (ex  (f:faculty)  (equal  ((relax  ta?)  t) 

((relax  faculty?)  f)))) 
axiom  (fa  (t:ta)  (ex  (s:student)  (equal  ((relax  ta?)  t) 

((relax  student?)  s)))) 


The  first  axiom  states  that  the  predicate  for  every  object  in  the  TA  class  there  is  an  object 


in  the  Faculty  class  such  that  if  the  ta?  predicate  and  faculty?  predicates  are  relaxed,  they  are  the 


same  underlying  Person.  The  second  axiom  does  the  same  for  the  Student  class. 
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The  next  set  of  axioms  define  ta-faculty  and  ta-student  operations  that,  in  essence,  relax  a  TA 
object  into  a  Faculty  or  Student  object.  The  definitional  axiom  states  that  if  a  relaxed  TA  object 
is  equal  to  a  relaxed  Faculty/ Student  object  then  the  result  of  the  ta-faculty /ta-student  operation 
is  the  Faculty/ Student  object.  These  relaxation  operations  are  used  to  define  the  equivalence  of 
attributes  defined  in  each  of  the  superclasses  respectively. 

op  ta-faculty  :  Ta  —  >  Faculty 

axiom  (implies  (equal  ((relax  ta?)  t)  ((relax  faculty?)  f)) 

(equal  (ta-faculty  t)  f)) 

op  ta-student  :  Ta  —  >  Student 

axiom  (implies  (equal  ((relax  ta?)  t)  ((relax  student?)  s)) 

(equal  (ta-student  t)  s)) 

The  operations  are  copied  from  the  superclasses  as  defined  for  single  inheritance.  The  only 
difference  is  that  the  definition  of  the  subclass  operations  must  be  based  on  where  the  operation 
is  originally  defined.  Thus  if  the  operation  is  defined  in  Person,  the  relax  operation  is  used  in  the 
definitions  whereas  if  the  operation  is  defined  in  Faculty,  the  ta-faculty  relaxation  operation  is  used 
in  the  definition. 

The  translation  of  0-Slang  multiple  inheritance  satisfies  the  three  requirements  for  inheri¬ 
tance  defined  in  Section  B.4.7.1.  First,  by  simulating  multiple  subsorting  through  the  definition  of 
superclass  relaxation  operations,  all  objects  of  the  subclass  are  objects  of  each  of  its  superclasses. 
Second,  all  operations  of  each  superclass  are  defined  on  the  subsort  since  they  are  explicitly  redefined 
(using  the  same  names  and  parameters)  on  the  subclass  objects.  Finally,  the  semantics  of  superclass 
operations  are  identical  on  operations  defined  in  the  superclasses  since  the  results  of  the  subclass 
operations  are  equivalenced  to  the  superclass  operations  over  the  superclass  attributes.  Therefore, 
the  translation  described  above  fully  specifies  the  semantics  of  0-Slang  multiple  inheritance. 
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B.5  Summary 


This  Appendix  defined  the  interpretation  of  0-Slang  in  Specware's  Slang,  thus  defin¬ 
ing  the  syntax  and  semantics  of  0-Slang.  Although  most  0-Slang  features  translate  simply, 
almost  trivially,  into  SLANG,  inheritance  requires  a  slightly  more  untidy  approach  due  to  Slang’s 
restricted  notion  of  subsorting.  While  the  inheritance  translation  increases  the  level  of  translation 
sophistication,  the  end  results  satisfy  the  requirements  of  the  substitution  property  as  defined  in 
Chapter  IV. 
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spec  FACULTY-STUDENT-COLIMIT  is 
colimit  of 

diagram  nodes  FACULTY,  STUDENT,  PERSON 
arcs  PERSON  -  >  FACULTY: 

{(FEMALE:  SEXUALITY)  -  >  (FEMALE:  SEXUALITY), 

(MALE:  SEXUALITY)  -  >  (MALE:  SEXUALITY), 

SEXUALITY  -  >  SEXUALITY, 

(YEAR:  DATE  -  >  INTEGER)  -  >  (YEAR:  DATE  -  >  INTEGER), 

(MONTH:  DATE  -  >  INTEGER)  -  >  (MONTH:  DATE  -  >  INTEGER), 

(DAY:  DATE  -  >  INTEGER)  -  >  (DAY:  DATE  -  >  INTEGER), 

(DEFAULT-DATE:  DATE)  -  >  (DEFAULT-DATE:  DATE),  DATE  -  >  DATE, 

(MAX:  INTEGER,  INTEGER  -  >  INTEGER) 

-  >  (MAX:  INTEGER,  INTEGER  -  >  INTEGER), 

(MIN:  INTEGER,  INTEGER  -  >  INTEGER) 

-  >  (MIN:  INTEGER,  INTEGER  -  >  INTEGER), 

(TIMES:  INTEGER,  INTEGER  -  >  INTEGER) 

-  >  (TIMES:  INTEGER,  INTEGER  -  >  INTEGER), 

(MINUS:  INTEGER,  INTEGER  -  >  INTEGER) 

-  >  (MINUS:  INTEGER,  INTEGER  -  >  INTEGER), 

(IPLUS:  INTEGER,  INTEGER  -  >  INTEGER) 

-  >  (IPLUS:  INTEGER,  INTEGER  -  >  INTEGER), 
(GREATER-THAN-OR-EQUAL:  INTEGER,  INTEGER  -  >  BOOLEAN) 

-  >  (GREATER-THAN-OR-EQUAL:  INTEGER,  INTEGER  -  >  BOOLEAN), 
(LESS-THAN-OR-EQUAL:  INTEGER,  INTEGER  -  >  BOOLEAN) 

-  >  (LESS-THAN-OR-EQUAL:  INTEGER,  INTEGER  -  >  BOOLEAN), 
(GREATER-THAN:  INTEGER,  INTEGER  -  >  BOOLEAN) 

-  >  (GREATER-THAN:  INTEGER,  INTEGER  -  >  BOOLEAN), 
(LESS-THAN;  INTEGER,  INTEGER  -  >  BOOLEAN) 

-  >  (LESS-THAN:  INTEGER,  INTEGER  -  >  BOOLEAN), 

(TEN:  INTEGER)  -  >  (TEN:  INTEGER), 

(NINE:  INTEGER)  -  >  (NINE:  INTEGER), 

(EIGHT:  INTEGER)  -  >  (EIGHT:  INTEGER), 

(SEVEN:  INTEGER)  -  >  (SEVEN:  INTEGER), 

(SIX:  INTEGER)  -  >  (SIX:  INTEGER), 

(FIVE:  INTEGER)  -  >  (FIVE:  INTEGER), 

(FOUR:  INTEGER)  -  >  (FOUR:  INTEGER), 

(THREE:  INTEGER)  -  >  (THREE:  INTEGER), 

(TWO:  INTEGER)  -  >  (TWO:  INTEGER), 

(ONE:  INTEGER)  -  >  (ONE:  INTEGER), 

(ZERO:  INTEGER)  -  >  (ZERO:  INTEGER),  INTEGER  -  >  INTEGER, 

PERSON  -  >  PERSON,  STRING  -  >  STRING, 

(CREATE-PERSON:  STRING  -  >  PERSON) 

-  >  (CREATE-PERSON:  STRING  -  >  PERSON), 

(CHANGE-NAME:  PERSON,  STRING  -  >  PERSON) 

-  >  (CHANGE-NAME:  PERSON,  STRING  -  >  PERSON), 

(SEX:  PERSON  -  >  SEXUALITY)  -  >  (SEX:  PERSON  -  >  SEXUALITY), 

(SSAN:  PERSON  -  >  INTEGER)  -  >  (SSAN:  PERSON  -  >  INTEGER), 
(BIRTHDAY:  PERSON  -  >  DATE)  -  >  (BIRTHDAY:  PERSON  -  >  DATE), 

(NAME:  PERSON  -  >  STRING)  -  >  (NAME:  PERSON  -  >  STRING)}, 

PERSON  —  >  STUDENT:  import-morphism 

end-diagram 


Figure  B.24  Slang  Faculty  Student  Colimit 
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spec  TA  is 

import  FACULTY-STUDENT-COLIMIT 
sort  Ta 

sort-axiom  Ta  =  Person  |  ta? 

axiom  (fa  (t:ta)  (ex  (f:faculty)  (equal  ((relax  ta?)  t) 

((relax  faculty?)  f)))) 
axiom  (fa  (t;ta)  (ex  (s;3tudent)  (equal  ((relax  ta?)  t) 

((relax  student?)  s)))) 

op  ta-faculty  ;  Ta  —  >  Faculty 

axiom  (implies  (equai  ((relax  ta?)  t)  ((relax  faculty?)  f)) 
(equal  (ta-faculty  t)  f)) 
op  ta-student  :  Ta  —  >  Student 

axiom  (implies  (equai  ((relax  ta?)  t)  ((relax  student?)  f)) 
(equal  (ta-student  t)  f)) 
op  name  :  Ta  —  >  String 
op  birthday  ;  Ta  —  >  Date 
op  ssan  :  Ta  —  >  Integer 
op  sex  ;  Ta  —  >  Sexuality 
op  academic-rank  :  Ta  —  >  Academic-Rank 


op  gpa  :  Ta  —  >  Gpa 
op  create-ta  ;  String  —  >  Ta 
op  change-name  :  TA,  String  —  >  TA 
op  ta?  :  Person  —  >  Boolean 
axiom  (fa  (p;person  t:ta) 

(implies  (equal  p  ((relax  ta?)  t)) 

(equal  (ta?  p) 

(and  (feculty?  p)  (student?  p))))) 
axiom  (fa  (t:ta)  (equal  (name  t)  (name  ((relax  ta?)  t)))) 
axiom  (fa  (t;ta)  (equal  (birthday  t)  (birthday  ((relax  ta?)  t)))) 
axiom  (fa  (t;ta)  (equal  (ssan  t)  (ssan  ((relax  ta?)  t)))) 
axiom  (fa  (t;ta)  (equal  (sex  t)  (sex  ((relax  ta?)  t)))) 
axiom  (fa  (t:ta)  (equal  (academic-rank  t) 

(academic-rank  (ta-faculty  t)))) 
axiom  (fa  (t:ta)  (equal  (gpa  t)  (gpa  (ta-student  t)))) 
axiom  (equal  (name  (create-ta  n))  (name  (create-person  n))) 
axiom  (equal  (birthday  (create-ta  n)) 

(birthday  (create-person  n))) 

axiom  (equal  (ssan  (create-ta  n))  (ssan  (create-person  n))) 
axiom  (equal  (sex  (create-ta  n))  (sex  (create-person  n))) 
axiom  (equal  (gpa  (create-ta  n)) 

(gpa  (create-student  n))) 
axiom  (equal  (academic-rank  (create-ta  n)) 

(academic-rank  (create-faculty  n))) 
axiom  (fa  (t;ta)  (equal  (name  (change-name  t  n)) 

(name  (change-name  ((relax  ta?)  t)  n)))) 
axiom  (fa  (t;ta)  (equal  (birthday  (change-name  t  n)) 

(birthday  (change-name  ((relax  ta?)  t)  n)))) 
axiom  (fa  (t:ta)  (equal  (ssan  (change-name  t  n)) 

(ssan  (change-name  ((relax  ta?)  t)  n)))) 
axiom  (fa  (t;ta)  (equal  (sex  (change-name  t  n)) 

(sex  (change-name  ((relax  ta?)  t)  n)))) 
axiom  (fa  (t;ta)  (equal  (gpa  (change-name  t  n)) 

(gpa  (change-name  (ta-student  t)  n)))) 
axiom  (fa  (t;ta)  (equal  academic-rank  (change-name  t  n)) 

(academic-rank  (change-name  (ta-faculty  t)  n)))) 


end-spec 


Figure  B.25  Slang  TA  Subclass 
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Appendix  C.  Generic  OMT  and  O- SLANG  ASTs 


C.l  Introduction 


This  appendix  contains  the  definition  of  the  0-Slang  and  GOMT  abstract  syntax  trees.  The 
notation  used  is  described  in  Table  C.l. 


Table  C.l  Abstract  Syntax  Tree  Notation 


Notation 

Meaning 

(...) 

Tuple 

{...} 

Set 

[...] 

Sequence 

1 

Logical  OR 

Mixed  Case 

Object 

Lower  Case 

Low-level  symbol/number 

Generally,  dot  notation  is  used  to  traverse  the  tree.  For  example,  if  C  is  a  class  in  a  GOMT  domain 
theory,  VT,  then 

C  e  Vr .GOMT-Class 

where  VT  .GOMT-Class  is  the  set  of  all  classes  in  the  domain  theory  VT.  Likewise,  for  some 
connection  c,  by  the  GOMT  AST  definition  below,  c  has  four  components.  Assume  c  is  defined  as 
shown  below. 


c.name 

c.Qualifier 

c.role 

c.Mult 


Pump 

{Pump-Number,  integer) 

undefined 

Many 


Then  the  connection  c  defines  a  connection  to  the  Pump  class  that  has  the  qualifier  Pump- 
Number  which  is  an  integer.  There  is  no  role  name  assigned  for  this  particular  connection  and  the 
multiplicity  is  defined  as  Many  (zero  or  more). 
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C.2  Generic  OMT  Abstract  Syntax  Tree 
GOMT-DomainTheory  =  <{GOMT-Class},  {Assoc}> 

GOMT-Class  =  <name,  {Superclass},  [Connection],  {Attribute},  {State}, 
{Transition},  {Axiom},  {GOMT-Op},  {Functional-Obj}> 

Assoc  =  <name,  [Connection],  {Attribute},  {G0MT-0p}> 

Connection  =  <name.  Qualifier,  role,  Mult> 

Qualifier  =  <name,  datatype> 

Mult  =  One  I  Many  I  Plus  |  Optional  I  Specified 

Plus  =  integer 

Specified  =  {Spec-Range} 

Spec-Range  =  <valuel,  value2> 

Attribute  =  DerivedAttr  I  NormalAttr 

DerivedAttr  =  <name,  {Axiom},  datatype> 

NormalAttr  =  <name,  {Axiom},  datatype> 

State  =  <name,  {Axiom},  {State}> 

Transition  =  <name,  [Parameter],  Axiom,  {Action},  FromState,  ToState> 
FromState  =  name 
ToState  =  name 

Action  =  <name,  [Parameter],  {Action}> 

GOMT-Op  =  <name,  [Parameter],  Result,  Definition> 

Result  =  datatype 
Parcuneter  =  <name,  datatype> 

Definition  =  {Axiom} 

Functional-Obj  =  Process  |  Datastore  |  Dataflow 
Process  =  <name ,  [InFlows] ,  [OutFlows] ,  {Process}> 

Datastore  =  <name,  [InFlows],  [OutFlows] > 
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InFlow  =  <name,  type> 


OutFlow  =  <name,  type> 

Dataflow  =  <name,  type,  source,  target> 
Superclass  =  superclass 
Subclass  =  subclass 


C.3  0-Slang  Abstract  Syntax  Tree 
0-Slang-DomainTheory  =  {Spec} 

Spec  =  Class  I  AbClass I  Event  I  Aggregate  |  Link  |  Association 

Class  =  <name,  ClassSort,  {Sort Axiom} ,  {Operation},  {Import},  {Sort}, 

{Attribute},  {Method},  {StateAttr},  {Event},  {State},  {Axiom}, 
contained- in> 

AbClass  =  <name,  ClassSort,  {SortAxiom},  {Operation},  {Import},  {Sort}, 
{Attribute},  {Method},  {StateAttr},  {Event},  {State}, 
{Axiom},  contained-in> 

Event  =  <name,  ClassSort,  {SortAxiom},  {Operation},  {Import},  {Sort}, 

{Attribute},  {Method},  {StateAttr},  {Event},  {State},  {Axiom}> 

Association  =  <name,  ClassSort,  {SortAxiom},  {Operation},  {Import}, 
{Sort},  {Attribute},  {Method},  {StateAttr},  {Event}, 
{State},  {Axiom},  link-class> 

Link  =  <name,  ClassSort,  {SortAxiom},  {Operation},  {Import},  {Sort}, 

{Attribute},  {Method},  {StateAttr},  {Event},  {State},  {Axiom}> 

Aggregate  =  <name,  {Node},  {Arc}> 

ClassSort  =  <class-sort-id,  {Inherited-Sort-Id}> 

SortAxiom  =  sort-id 

Import  =  class-ref 

Sort  =  sort-id 

Inherited-Sort-Id  =  sort-id 

Operation  =  <name,  [Domain- Ident] ,  [Range-Ident] > 

Attribute  =  <name,  [Domain-Ident] ,  [Range-Ident] > 
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StateAttr  =  <name,  [Domain-Ident] ,  [Range-Ident] > 
Method  =  <name,  [Domain-Ident],  [Range-Ident] > 
Event  =  <name ,  [Domain-Ident] ,  [Range-Ident] > 
State  =  <name,  [Domain-Ident],  [Range-Ident] > 

Node  =  <name,  class-ref > 

Arc  =  <arc-from-node,  arc-to-node,  {NodeHap3-> 
NodeMap  =  <map-from,  map-to,  FromOp,  ToOp> 

FromOp  =  <name,  [Domain-Ident] ,  [Range-Ident] > 
ToOp  =  <name,  [Domain-Ident],  [Range-Ident] > 
Domain-Ident  =  sort-id 
Range-Ident  =  sort-id 
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Appendix  D.  Demonstration  System 


D.  1  Introduction 

This  Appendix  documents  the  implementation  of  a  graphical,  object-oriented  user  interface 
used  in  the  proof-of-concept  demonstration  of  a  parallel  refinement  specification  acquisition  system. 
The  goal  of  this  demonstration  is  to  show  that  Rumbaugh’s  Object  Modeling  Technique  (OMT) 
diagrams  (83)  can  be  automatically  transformed  into  theory-based  specifications  consistent  with 
the  original  diagrams,  not  to  demonstrate  a  complete  parallel  refinement  environment.  This  Ap¬ 
pendix  informally  presents  the  method  used  to  obtain  a  generic  OMT  abstract  syntax  tree  (AST) 
representation. 

To  simplify  implementation  of  the  demonstration  software,  a  commercially  available  object- 
oriented  drawing  package,  ObjectMaker^ ,  was  used  to  implement  the  user  interface.  A  diagram 
of  the  demonstration  system  is  shown  in  Figure  D.l.  Rumbaugh  OMT  diagrams  are  developed  in 
ObjectMaker  and  exported  to  external  .TAT files.  A  .TEXT  file  allows  the  user  to  overcome  some 
shortcomings  of  ObjectMaker  by  manually  entering  data  not  handled  properly  by  ObjectMaker. 
These  files  are  converted  to  a  different  format,  via  the  program  read.c,  and  merged  into  a  single 
OMT  specification.  This  specification  is  parsed  into  a  Refine^  AST  using  a  parser  developed  in 
Dialect^.  Once  in  Refine,  a  rule-based  conversion  program  transforms  the  ObjectMaker  OMT  AST 
into  the  Generic  OMT  (GOMT)  AST  as  defined  in  Appendix  A. 

A  brief  overview  of  ObjectMaker  is  presented  in  Section  D.2  followed  by  a  description  of  the 
ObjectMaker  specific  OMT  parser  in  Section  D.3.  Finally,  the  ObjectMaker  OMT  AST  to  GOMT 
AST  transformation  program  is  discussed  in  section  D.4. 

^ObjectMaker  is  a  registered  trademark  of  Mark  V  Systems  Limited  Encino  California 
^Refine  is  a  trademark  of  Reasoning  Systems  Inc.  Palo  Alto  California 
®  Dialect  is  a  trademark  of  Reasoning  Systems  Inc.  Palo  Alto  California 


D-1 


1 

ObjectMaker 

« 

S!?:  Ot^ectMakS^i  ExfxHt 

Refine 

.TXT 

files 

rea<i.c  .  f  A 

ObjecMaker 
OMT  spec 

iM  ObjectMaker 

^  ‘IT  AST 

MANUALTE)Cr 

r  :: 

1 

con  Brt 

H  Generic  1 
m  OMT  AST 

Figure  D.l  ObjectMaker  to  GOMT  Transformation  System 


D.2  ObjectMaker 

ObjectMaker  is  a  commercially  available  object-oriented  drawing,  code  generation,  and  re¬ 
engineering  tool.  It  supports  many  object-oriented  design  techniques  including  Rumbaugh’s  OMT. 
An  example  of  an  ObjectMaker  window  is  shown  in  Figure  D.2. 

In  ObjectMaker,  OMT  diagrams  are  created  and  stored  in  project  repositories.  Actually, 
diagrams  are  stored  separately;  however,  the  information  contained  on  the  diagrams  is  stored  in 
repositories.  Rumbaugh  diagrams  supported  by  ObjectMaker  include  the  Dynamic  Model,  Event 
Flow  diagram.  Event  Trace  diagram.  Functional  Model,  and  Object  Model.  With  a  few  exceptions, 
ObjectMaker  allows  the  user  to  draw  diagrams  as  described  by  Rumbaugh.  Specific  problems  with 
ObjectMaker  are  enumerated  below. 


1.  Does  not  allow  aggregate  qualifiers. 

2.  Lacks  an  adequate  device  for  inserting  constraints  at  the  class  level. 

3.  Lacks  the  ability  to  define  operation  semantics. 

4.  Does  not  capture  substate-superstate  relationships. 

5.  Does  not  capture  subprocess-superprocess  relationships. 
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Figure  D.2  ObjectMaker  Window 


6.  Does  not  provide  links  between  classes  and  their  dynamic  and  functional  diagrams. 

7.  Intermittent  problems  in  mapping  diagrams  to  their  repositories  and  exporting  repositories 
to  text  files. 

The  first  five  problems  with  ObjectMaker  listed  above  involved  the  inability  of  ObjectMaker 
to  capture  the  entire  Rumbaugh  model.  These  problems  were  alleviated  by  using  manual  data  entry 
as  described  in  Section  D.2.1.  Item  six,  lack  of  a  link  between  object  classes  and  their  dynamic 
and  functional  models,  was  overcome  through  a  naming  convention.  Because  ObjectMaker  does 
store  the  diagram  on  which  particular  dynamic  and  functional  concepts  reside,  I  required  the  first 
word  in  the  diagram  name  to  be  the  name  of  the  associated  object  class.  This  work  around  solved 
the  problem.  The  last  item  listed  above,  intermittent  problems  mapping  and  exporting  data,  is  a 
nuisance  but  not  a  fatal  flaw.  Inconsistencies  between  the  diagrams  and  the  repository  occur  quite 
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often,  with  no  messages  or  explanations  from  ObjectMaker,  requiring  the  user  to  completely  rebuild 
the  repositories  from  scratch.  Then,  once  the  repository  and  the  diagrams  do  match,  exporting  the 
repositories  is  often  incomplete  due  to  errors;  however,  ObjectMaker  does  report  these  errors  to 
the  user.  Exiting  ObjectMaker  and  re-exporting  generally  solves  the  problem. 

D.2.1  Manual  Text  File.  As  stated  above,  to  workaround  the  inability  of  ObjectMaker 
to  capture  certain  vital  data,  a  manually  created  text  file,  MANUAL.TEXT,  is  used  to  augment 
the  .TXT  files  exported  by  ObjectMaker.  An  example  MANUAL.TEXT  file  is  shown  in  Figure 
D.3.  Five  types  of  data  may  be  entered  in  MANUAL.TEXT;  aggregate  qualifiers,  class  constraints, 
method  definitions,  substate  definitions,  and  subprocess  definitions.  Each  of  these  is  shown  in  Figure 
D.3.  The  aggregate  qualifier,  substate  definition,  and  subprocess  definition  simply  state  that  a  rela¬ 
tionship  exists  between  a  qualifier/substate/subprocess  and  its  associated  aggregate/state/process. 
The  class-constraints  allows  the  user  to  enter  general  class  constraints  via  first-order  axioms.  These 
constraints  may  be  constraints  on  attribute  values  or  state  invariants.  Method  definitions  define 
the  effect  of  a  method  on  each  attribute  defined  in  its  class.  Once  again,  these  definitions  are  in 
the  form  of  a  set  of  first-order  axioms.  The  first  line  in  the  definition  defines  the  method’s  class. 

The  MANUAL.TEXT  file  is  merged  directly  into  the  OMT  specification  which  is  parsed  into 
the  ObjectMaker  OMT  AST.  ObjectMaker  does  have  the  capability  to  manually  enter  some  the 
data  found  in  MANUAL.TEXT;  however,  this  manually  entered  data  is  lost  whenever  the  repository 
becomes  inconsistent  and  has  to  be  rebuilt. 

D.3  OMT  Parser 

The  ObjectMaker  OMT  parser  is  defined  in  Refine  Dialect  and  is  used  to  parse  ObjectMaker 
OMT  specifications  into  a  Refine  AST.  The  ObjectMaker  OMT  AST  mirrors  the  ObjectMaker 
OMT  specification  language  and  was  only  intended  as  a  convenient  way  to  get  the  ObjectMaker 
OMT  specification  into  a  Refine  AST  where  it  is  more  easily  manipulated  and  transformed  into  the 
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aggregate:  Pump  has  qualifier  display-id  to  component  Display. 


class-constraints:  Display 

display-state(d)  =  zero-display  =>  cost(d)  =  0  &  volume(d)  =  0; 
display-state(d)  =  increment-display  =>  cost(d)  >=  0  &  volume(d)  >=  0; 
cost(d)  >=  0; 
volume(d)  >=  0 
end  class-constraints. 

definition:  update-display 
cIeuss  =  display; 

update-display(d)  =  update-cost(update-volume(d)) 
end  definition. 

deflnition:  update-volume 
class  =  display; 

grade(update-cost(d))  =  grade(d); 
volume(update-volume{d))  =  volume(d)  -|-  1; 
cost(update-cost(d))  =  cost(d) 

end  definition. 

definition:  update-cost 
class  =  display; 

grade(update-cost(d))  =  grade(d); 
volume(update-cost(d))  =  volume(d); 
cost(update-cost(d))  =  cost(d)  -|-  1 

end  definition. 

definition:  zero-out-display 
cIelss  —  display; 

grade(update-cost(d))  =  grade(d); 
cost(zero-out-display(d))  =  0; 
volume(zero-out-display(d))  =  0 
end  deflnition. 

substate  Locked  <  state  Display-On  . 
substate  Running  <  state  Display-On  . 

subprocess  update-volume  <  process  update-display, 
subprocess  update-cost  <  process  update-display. 

Figure  D.3  MANUAL.TEXT  Example 


GOMT  AST.  I  decided  not  to  attempt  to  parse  the  ObjectMaker  OMT  specification  directly  into 
the  GOMT  AST  due  to  the  required  complexity  of  the  required  parser.  No  semantic  processing 
is  done  on  the  ObjectMaker  OMT  specification  after  being  parsed  into  the  AST.  All  semantic 
processing  is  done  after  the  conversion  to  the  GOMT  AST  described  in  the  next  section. 


D.4  ObjectMaker  OMT  AST  to  GOMT  AST  Transformation 

Transformation  from  the  ObjectMaker  OMT  AST  and  the  GOMT  AST  is  accomplished 
through  a  rule-based  Refine  program.  This  transformation  program  takes  individual  objects  from 
the  ObjectMaker  OMT  AST  and  transforms  them  into  the  appropriate  GOMT  AST  object.  There 
are  four  phases  to  the  transformation  process:  (I)  creation  of  class  and  association  objects,  (II) 
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creation  of  dynamic  and  functional  objects  for  each  class,  (III)  filling  in  attributes  of  objects  defined 
in  phases  two  and  three,  and  (IV)  checking  redundant  information  for  consistency. 

Because  ObjectMaker  exports  its  repositories  in  a  series  of  fiat  files  with  redundant  informa¬ 
tion,  the  ObjectMaker  OMT  AST  reflects  that  architecture;  therefore,  the  transformation  process 
must  be  completed  in  steps.  Since  the  basic  objects  in  the  GOMT  AST  are  classes  and  associations, 
these  objects  must  be  created  before  ObjectMaker  OMT  AST  objects  that  are  logically  a  part  of 
a  class  or  association  are  transformed.  Therefore,  in  the  first  transformation  phase,  only  the  root, 
class,  and  association  objects  are  allowed  to  be  transformed.  During  the  preorder  traversal  of  the 
ObjectMaker  OMT  AST,  each  object  and  association  object  encountered  causes  the  appropriate 
class  or  association  object  to  be  created  in  the  GOMT  AST.  Any  attributes,  partitions,  opera¬ 
tions,  constraints,  or  superclasses  defined  in  the  class  object  get  transformed  into  the  appropriate 
attribute  in  the  new  class  object.  Likewise,  any  association  classes,  attributes,  or  operations  are 
also  transformed  into  the  new  AST. 

Once  all  the  basic  classes  and  associations  have  been  created  in  the  GOMT  AST,  the  dynamic 
model  objects  (state  and  transitions)  and  functional  model  objects  (actors,  processes,  dataflows, 
and  datastores)  are  created  and  attached  to  their  appropriate  classes  defined  in  phase  I.  It  is  in 
this  phase  that  the  transformation  system  uses  the  diagram  names  to  determine  which  class  owns 
the  dynamic  and  functional  model  components.  If  the  class  specified  by  the  diagram  name  has  not 
been  created,  error  messages  are  generated. 

After  all  the  functional  and  dynamic  model  components  have  been  transformed  and  attached 
to  their  owning  classes,  the  attributes  specified  in  various  ObjectMaker  OMT  AST  objects  are  used 
to  fill  in  the  existing  class,  association,  functional,  and  dynamic  objects.  Information  transformed 
in  this  step  includes  association  and  aggregate  role  names,  and  qualifiers;  operation  parameters, 
results,  and  axioms;  substate  and  subprocess  relationships;  attribute  datatype  and  initial  value  or 
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derivation  axioms;  and  inheritance  information.  During  phase  III  all  duplicate  data  in  the  objects 
being  transformed  is  checked  against  the  existing  objects  to  ensure  consistency. 

Once  phase  III  is  completed,  the  entire  GOMT  AST  is  complete.  The  only  phase  left  is  con¬ 
sistency  checking.  There  is  only  one  ObjectMaker  OMT  AST  object  that  is  completely  redundant: 
the  generalization  object.  This  object  is  used  to  ensure  that  all  superclass  -  superclass  relationships 
have  been  captured. 

Once  phase  IV  is  completed,  the  GOMT  AST  is  complete.  There  is  no  semantic  processing 
for  this  tree.  All  semantic  processing  is  done  during  or  after  transformation  to  the  0-Slang  AST 
as  discussed  in  Chapter  VII. 

D.5  GOMT  AST  to  0-Slang  Transformation 

Once  in  the  GOMT  AST,  a  rule-based  transformation  program  implementing  the  transfor¬ 
mation  rules  defined  in  Chapter  VII  transforms  the  GOMT  AST  into  an  0-Slang  AST  within  the 
Refine  environment.  This  transformation  process  is  much  like  the  process  for  transforming  the  Ob¬ 
jectMaker  AST  into  the  GOMT  AST  except  it  carries  out  the  transformation  in  one  phase.  Once 
in  a  valid  0-Slang  AST,  the  Dialect  pretty  printer  is  used  to  produce  a  textual  representation  of 
the  0-Slang  AST. 

The  actual  transformation  is  performed  by  creating  the  root  node  of  the  0-Slang  AST  and 
then  automatically  transforming  each  class  and  association,  one  at  a  time,  within  the  GOMT  AST. 
The  only  sequencing  done  in  the  transformation  is  done  to  ensure  that  all  component  classes  of  an 
aggregate  are  transformed  before  the  aggregate  itself  is  transformed. 

In  its  current  state,  the  GOMT  to  0-Slang  transformation  system  converts  almost  all  of  the 
GOMT  AST  objects  correctly  into  0-Slang  with  the  following  exceptions. 

1.  Multiple  Event  Theories 
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2.  Super/Substate  Axiom  Generation 


3.  Multiple  Parameter  Events 

4.  Association  and  Aggregate  Qualifiers 

These  items  were  not  implemented  because  I  did  not  consider  the  time  required  to  implement 
and  debug  them  useful.  None  of  these  items  were  omitted  due  to  the  inability  to  implement  them. 

D.  6  Summary 

This  appendix  documents  the  use  of  the  object-oriented  drawing  tool  ObjectMaker  as  a  front 
end  for  the  user  interface  of  a  parallel  refinement  specification  acquisition  system.  Data  is  exported 
from  ObjectMaker,  merged  with  additional  manually  entered  data,  and  parsed  into  an  AST  based 
on  the  ObjectMaker  output  files.  This  AST  is  then  transformed  via  a  rule-based  Refine  program 
into  the  GOMT  AST  which  is  used  as  the  starting  point  for  a  formal  transformation  from  OMT 
to  theory-based  specifications.  A  conversion  system  for  the  GOMT  to  0-Slang  transformation, 
based  on  the  rules  defined  in  Chapter  VII,  was  developed  and  used  to  produce  the  demonstration 
examples  shown  in  Chapter  VIII. 


D-8 


Appendix  E.  Additional  Theories 


Specification  of  Triv 


spec  Triv  is 
sorts  E 
end-spec 
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Specification  of  Set 


spec  Set  is 
import  INTEGER 
sorts  E,  Set 
constants 
empty-set:  Set 
operations 

in  :  E,  Set  — >  boolean 
empty?  :  Set  — >  boolean 
insert  :  E,  Set  — »  Set 
singleton  :  E  — >  Set 
union  :  Set,  Set  — >  Set 
delete  :  E,  Set  Set 
size  :  Set  integer 
subset  :  Set,  Set  — >  boolean 
constructors  {insert,  empty-set}  construct  Set 
constructors  {union,  singleton,  empty-set}  construct  Set 
axioms 

union(x,y)  =  union(y,x); 
union(x,union(y,z))  =  union(union(x,y)  z); 
union(x, empty-set)  =  x; 
union(empty-set  x)  =  x; 
union(x,x)  =  x; 
definition 

in(x,insert(y,c))  x  =  y  V  in(x,c); 
in(x, empty-set)  =  false; 
end-definition 
definition 
theorem 

empty?(insert(x,c))  =  false; 
empty?(empty-set)  =  true; 
end-definition 
definition 

in(x,union(u,v))  ^  in(x,u)  V  in(x,v)); 
in(x,singleton(x))  =  true; 
in(x, empty-set)  =  false; 

end-definition 

definition 

empty?(union(u,v))  -O-  empty?(u)  A  empty?(v); 
empty?  (singleton(x))  =  false; 
empty?  (empty-set)  =  true; 

end-definition 
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definition  of  delete  is 

delete(x, empty-set)  =  empty-set; 
delete(x,insert(x,s))  =  s; 

xl  x2  ^  delete(xl,insert(x2,s))  =  insert(x2,delete(xl,s)); 

end-definition 

definition  set-equal-def  of  equal  is 
s  =  t  ^  (V  (x:E)  in(x,s)  •«>  in(x,t)); 
end-definition 
definition  set-size-def  of  size  is 
size(empty-set)  =  0; 
in(e,s)  size(insert(e,s))  =  size(s); 

-1  in(e,s)  =>  size(insert(e,s))  =  size(s)  -|-  1; 
in(e,s)  =>■  size(delete(e,s))  =  size(s)  —  1; 

-I  in(e,s)  size(delete(e,s))  =  size(s); 
end-definition 

definition  subset-def  of  subset  is 
subset(sl,s2)  =  in(e,sl)  in(e,s2); 

end-definition 

end-spec 
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Specification  of  Integer 


spec  Integer  is 
sorts  Integer 
operations 

zero  :  — >  Integer 
one  :  — >  Integer 

<  :  Integer,  Integer  —y  Boolean 

>  :  Integer,  Integer  —y  Boolean 

<  :  Integer,  Integer  —y  Boolean 

>  :  Integer,  Integer  —y  Boolean 
+  :  Integer,  Integer  Integer 
—  :  Integer,  Integer  — >  Integer 
X  :  Integer,  Integer  —y  Integer 
min  :  Integer,  Integer  — >  Integer 
max  :  Integer,  Integer  — >  Integer 

axioms 

(zero  <  one); 

(x  <  x); 

(x  <  y)  V  (y  <  x); 

(x  <  y)  A  (y  <  z))  (x  <  z); 

(x  <  y)  A  (y  <  x))  (x  =  y); 

(x  >  y)  ((y  +  one)  <  x); 

(x  <  y)  ((x  +  one)  y); 

((y  +  one)  <  x))  (x  <  y); 

(x  >  y)  ^  (y  <  x); 

(x  +  y)  =  (y  +  x); 

(x  +  (y  +  z))  =  ((x  +  y)  +  z); 

((x  +  y)  +  z)  =  (x  +  (y  +  z)); 

(x  +  zero)  x); 

(x  -  x)  zero); 

((z  -  x)  -  y)  =  (z  -  (x  +  y)); 

((x  +  y)  =  (x  +  z))  O  (y  =  z); 

(x  <  (y  -  z))  ((x  +  z)  <  y); 

((x  -  y)  <  z)  (x  <  (y  +  z)); 

((y  +  x)  =  (z  +  x))  ^  (y  =  z); 

((zero  <  x)  A  (zero  <  y))  =>■  (zero  <  (x  +  y)); 

(y  zero)  =>  ((x  x  y)  =  zero); 

(y  =  one)  =>  ((x  x  y)  =  x); 

((“’  (y  =  zero))  A  (-.  (y  =  one)))  ((x  x  y)  =  (((x  +  (y  -  one))  x  x)) 
(x  <  y)  =4-  (min(x,y)  =  x); 

(x  >  y)  (min(x,y)  =  y); 

(x  >  y)  (max(x,y)  =  y); 

(x  >  y)  (max(x,y)  =  x) 
end-spec 
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Appendix  F.  Translation  Correctness 


In  this  Appendix,  I  prove  Theorems  VII.l,  VII.2,  and  VII.3.  These  theorems  show  that  the 
transformation  rules  as  defined  in  Chapter  VII  preserve  the  semantics  of  the  the  object  model,  the 
dynamic  model,  and  the  functional  model  as  defined  Chapter  V. 

F.l  Object  Model  Correctness  Proof 

In  this  section.  Theorem  VII.l  is  proved. 

Proof.  Preservation  of  the  object  model  semantics  by  r  is  established  by  showing  the  equiv¬ 
alence  of  two  sets  of  object  model  semantics,  OM  and  OM',  created  from  a  generic  OMT  domain 
theory,  Q.  OM  is  the  object  model  semantics  defined  by  transforming  G  hy  (p  while  OM'  is  the 
object  model  semantics  defined  by  transforming  G  by  r,  into  an  0-Slang  domain  theory  O,  and 
then  by  u).  In  this  proof,  I  assume  that  G  has  a  well  defined  object  model  in  which  C  is  a  class  and 
A  is  an  association. 

I  prove  the  theorem  by  showing  that,  given  a  valid  generic  OMT  domain  theory  G,  each 
component  (Name,  Imports,  Sorts,  Operations,  and  Axioms)  of  each  specification  in  OM  exists  in 
OM'  and  that  each  component  of  each  specification  in  OM'  exists  in  OM.  I  start  by  proving  that 
the  set  of  specifications  in  OM  and  OM'  are  equivalent  and  then  complete  the  proof  by  showing 
that  each  component  within  those  specifications  are  equivalent. 

1.  In  this  section  I  show  that  the  set  of  specifications  in  OM  and  OM'  are  equivalent  by  showing 
for  any  specification  in  OM,  there  is  a  corresponding  specification  on  OM'  and  vice  versa. 

S  £  OM  =>■  S'  E  OM' .  If  Sc  is  some  specification  in  OM,  it  must  have  been  generated 
by  Equation  7.40  {S  is  a  class  specification  Sc)  or  7.49  {S  is  an  association  specification  Sa)- 
If  5  is  a  class  then  by  Equation  7.40,  there  must  exist  a  class  C  in  ^  such  that  C.Name  = 
Sc-Name.  Then  by  OMT-1  or  OMT-2  there  exists  a  class  C  in  O  such  that  C.Name  = 
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C.Name  =  Sc-Name  that  in  turn,  by  Equation  7.58,  generates  a  class  S'q  in  OM'  such  that 
Sp.Name  =  C.Name  =  Sc-Name. 

If  S  is  an  association  then  by  Equation  7.49  there  must  exist  an  association  A  va.  Q  such 
that  A.Name  =  SA-Name.  Then  by  OMT-44  there  exists  an  association  A  in  O  such  that 
k.Name  =  A.Name  =  SA-Name  that  in  turn,  by  Equation  7.68,  generates  an  association 
S'j^  in  OM'  such  that  S'j^.Name  =  C.Name  =  SA-Name. 

S'  €  OM'  =>•  i?  €  OM.  If  S'  is  some  specification  in  OM',  it  must  have  been  generated  by 
Equation  7.58  {S'  is  a  class  specification  S'^)  or  7.68  {S'  is  an  association  specification  5^). 
If  S'  is  a  class  then  by  Equation  7.58  there  must  exist  a  class  C  in  O  such  that  C.Name  = 
S'q. Name.  Then,  since  OMT-1  or  OMT-2  are  the  only  rules  in  t  that  create  simple  classes 
in  O,  there  exists  a  class  C  in  Q  such  that  C.Name  =  C.Name  =  S'q. Name  that  in  turn,  by 
Equation  7.40,  generates  a  class  Sc  in  OM  such  that  Sc-Name  =  C.Name  =  S'q. Name. 

If  S'  is  an  association  then  by  Equation  7.68  there  must  exist  an  association  A  in  O  such 
that  A.Name  =  S'^.Name.  Then,  since  OMT-44  is  the  only  rule  that  creates  associations 
in  O,  there  exists  an  association  .4  in  ^  such  that  A.Name  =  k.Name  =  S'^^.Name  that  in 
turn,  by  Equation  7.49,  generates  an  association  Sa  in  OM  such  that  SA.Name  =  C.Name 
=  S'j^.Name. 

Therefore,  since  S  G  OM  ^  S"  G  OM',  OM  C  OM'  and  since  S'  G  OM'  ^  S  E  OM., 
OM'  C  OM,  therefore,  the  set  of  specifications  in  OM  and  OM'  are  equivalent.  Now  I  show 
that  each  item  in  associated  specifications  in  OM  and  OM'  are  equivalent. 

2.  Imports 

i  G  S. Imports  i'  E  S'  .Imports.  Within  each  specification  S  E  OM,  there  is  a  set  of 

imported  specifications  whose  names  are  in  S. Imports.  In  the  definition  of  (p,  there  are  three 
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equations  that  map  names  into  S.Imports:  Equations  7.41,  7.48,  and  7.50.  Each  of  these 
possibilities  is  analyzed  below. 

(a)  If  a  specification  name  s  €  S.Imports  is  generated  via  Equation  7.41,  then  i  represents 
the  datatype  of  an  attribute  and  thus  there  exists  an  attribute  a  =  {a.name,,  axiom, 
i)  £  C  such  that  i  is  the  datatype  of  a.  If  a  is  a  normal  attribute,  OMT-13  generates 
an  attribute  {a.Name,  [C.iVame],  [i])  €  C.Attribute  and  by  Equation  7.59  in  w,  Range- 
Ident{l)  =  i  £  Sc-Imports.  If  a  is  a  derived  attribute,  OMT-14  generates  an  operation 
{a.Name,  [CiVarne],  [i]}  €  ^.Operation  and  by  Equation  7.60  in  u,  Range-Ident{\)  = 
i  G  S^.Imports. 

(b)  If  i  G  Sc-Imports  is  generated  by  Equation  7.48,  then  by  Equation  7.48  there  exists 
a  c  G  C. Superclass  such  that  c  =  i.  Then,  by  OMT-4,  i  G  C. Superclass  generates 
an  i  in  C.class-sort.inherited-class-id  that  in  turn,  by  Equation  7.67,  inserts  i  into 
S'q. Imports. 

(c)  If  i  G  SA-Ituports  is  generated  by  Equation  7.50,  then  i  must  be  the  name  of  a  connection 
in  A.  Then  by  OMT-46,  if  i  is  the  name  of  some  c  in  A.Connection  there  exists 
an  operation  o  =  {IMAGE,  [K.Name,c.Name],  [a:])  G  ^.Operation  that  in  turn,  by 
Equation  7.69,  places  c.Range-Ident{2)  =  i  in  S'^.Imports.  Therefore,  if  i  G  S.Imports, 
i  G  S'  .Imports. 

Therefore,  since  for  each  possible  source  of  i  in  5  (Equations  7.41,  7.48,  and  7.50),  if  i 
was  generated  by  that  equation  then  i  G  S.Imports  i  G  S'. Imports  and  S.Imports  C 
S'  .Imports. 

i'  G  S'  .Imports  =>  i  £  S.Imports.  If  i'  G  S'  .Imports,  there  are  four  possible  sources  - 
Equations  7.59,  7.60,  7.67,  or  7.69.  Each  is  analyzed  below. 
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(a)  If  the  source  of  i  G  S'  .Imports  is  Equation  7.59,  then  there  must  be  some  attribute  a 
G  C.Attribute  such  that  a.Range-Ident  =  [i]  and  i  is  not  a  class  set  or  association  sort. 
The  only  transformation  capable  of  creating  such  an  attribute  in  C  from  Q  is  OMT-13. 
Thus  by  OMT-13  there  must  be  some  a  in  C.Attribute  such  that  i  =  type{a)  and  by 
the  assumption  that  all  attributes  have  defined  datatypes  i  =  a.datatype.  Therefore,  by 
Equation  7.41  in  transformation  (p,  a.datatype  G  S.Imports  and  thus  i  G  S. Imports. 

(b)  If  the  source  of  f  G  S'. Imports  is  Equation  7.60,  then  there  must  be  some  operation 
o  G  C.Operation  such  that  i  G  o.Range-Ident.  The  only  transformation  that  creates 
such  an  operation  in  C  from  Q  is  OMT-14.  (Actually,  OMT-15  and  OMT-90  could  also 
create  operations  in  C;  however,  OMT-15  creates  the  attr-equal  operation  and  OMT-90 
creates  operations  manually  defined  by  the  user  that,  by  assumption,  do  not  exist.)  Thus 
by  OMT-14  there  must  be  some  a  in  C.Attribute  such  that  i  =  =  a.datatype  and  by 
Equation  7.41  in  ip,  a.datatype  G  S.Imports  and  thus  i  G  S.Imports. 

(c)  If  the  source  of  i  G  S'. Imports  is  Equation  7.67  then  i  must  be  a  sort  in  C.Class- 
Sort.Inherited-Sort-Id.  Since  OMT-4  is  the  only  transformation  that  generates  sorts  in 
C.Class-Sort. Inherited-Sort-Id,  it  must  be  the  c^lse  that  i  is  in  C. Superclass  and  thus, 
by  p  Equation  7.48,  i  G  S.Imports. 

(d)  Finally,  if  the  source  of  i  G  S'. Imports  is  Equation  7.69  then  i  must  be  o.Domain- 
Ident{2)  in  some  operation  named  IMAGE  in  ^Operation.  Since  OMT-46  is  the  only 
transformation  in  r  capable  of  placing  an  IMAGE  operation  in  k.Operation  and  (OMT- 
49  defines  qualified  operations  that,  by  assumption,  are  not  included  in  ^),  i  must  be 
the  name  of  some  connection,  c,  in  A  and  thus  i  =  c.Name.  Then  by  Equation  7.50 
s.Name  G  S.Imports  and  thus  i  G  S.Imports. 

Therefore,  since  for  each  possible  source  of  i  in  S'  (Equations  7.59,  7.60,  7.67,  and  7.69),  if 
i  was  generated  by  that  equation  then  i  G  S'. Imports  =>■  f  G  S.Imports  and  S'. Imports  C 


F-4 


S.Imports.  Also,  since  I  already  established  that  S.Imports  C  S'  .Imports,  it  must  be  the 
case  that  S.Imports  =  S'  .Imports. 

3.  Sorts 

s  €  S. Sorts  ^  s'  £  S'.Sorts.  Within  each  specification  S  £  OM,  there  is  a  set  of  sorts 
defined  by  placing  their  names  in  S.Sorts.  In  the  definition  of  (p,  there  are  two  equations  that 
map  names  from  G  into  S.Sorts:  Equations  7.40  and  7.49.  Since,  as  shown  in  Item  1  above 
using  Equations  7.40  and  7.49,  any  S  £  OM  with  name  n  ^  3  S'  e  OM'  with  name  n  and 
by  Equations  7.58  and  7.68  if  n  =  S'. Name  then  n  £  S'. Sort.  Therefore  S.Sorts  C  S'.Sorts. 

s  £  S'.Sorts  =»  3  £  S.Sorts.  In  the  definition  of  w,  there  are  two  equations  that  map 
from  C  into  S'.Sorts:  Equations  7.58  and  7.68.  Since,  as  shown  in  Item  1  above  using 
Equations  7.58  and  7.68,  if  S'  €  OM'  and  S'. name  =  n  then  there  exists  an  S'  £  OM  with 
S.name  =  n  as  well.  And  since  S  was  created  by  either  Equation  7.58  or  7.68,  this  implies  n 
£  S.Sort.  Therefore  S'.Sorts  C  S.Sorts  and  since  S.Sorts  C  S'.Sorts,  it  must  be  true  that 
S.Sorts  =  S'.Sorts. 

4.  Operations 

o  £  S. Operations  =>  o'  £  S'  .Operations.  If  o  £  S.Operations,  there  are  four  possible 

sources  of  o  as  transformed  from  G-  Equations  7.41,  7.42,  7.48,  and  7.50.  Each  of  these 
possibilities  is  analyzed  below. 

(a)  If  the  source  of  o  £  S.Operations  is  Equation  7.41  then  o  =  {a.Name,  [C.Name], 
[a.Datatype])  for  some  a  in  C. Attribute.  If  this  a  is  a  normal  attribute,  then  by  OMT- 
13  {a.Name,  [C.Name],  [a.Datatype])  £  <C.Attribute  and  by  Equation  7.59,  {a.Name, 
[C.Name],  [a.Datatype])  =  {a.Name,  [C.Name],  [a.Datatype])  £  S'  .Operations. 
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If,  however,  a  is  a  derived  attribute,  then  by  OMT-14  {a. Name,  [C.Name],  [a. Datatype]) 
e  ^.Operation  and  by  Equation  7.60,  {a.Name,  [CA^ame],  [a.Datatype])  =  {a.Name, 
[C.Name],  [a.Datatype])  €  S'  .Operations. 

(b)  If  the  source  of  o  6  S.Operations  is  Equation  7.42  then  o  =  (HAS-PART,  [C.Name, 
C.Name],  [Boolean])  or  o  =  {c.Role,  [C.Name,  c.Name],  [Boolean])  for  some  c  e 
C.Connection  based  on  whether  c.Role  is  defined. 

i.  If  c.Role  is  defined,  then  by  OMT-5,  {c.Role,  [C.Name],  [c.Name-CLASS])  € 
C.Attribute  and  by  u  Equation  7.61,  {c.Role,  ]^.Name,c.Nam^,  [Boolean^  = 
{c.Role,  [C.Name, c.Nam^,  [BooZean])  =  o  6  S'  .Operations. 

ii.  If  c.Role  is  not  defined,  then  by  OMT-5,  {c.Name-OBJ,  [C.Name],  [c.Name- 
CLASS])  €  C.Attribute  and  by  w  Equation  7.61,  {HAS-PART,  [C.Name,  c.Name], 
[Boolean])  =  {HAS-PART,  [C.Name,  c.Name],  [Boolean])  =  o  €  S'  .Operations. 

(c)  If  the  source  of  o  €  S.Operations  is  Equation  7.48  then  o  =  {SIMULATES,  [C.Name], 
[c])  for  some  c  €  C. Superclass.  Then  by  OMT-4,  c  G  C. Superclass  implies  c  €  C.Class- 
Sort. Inherited-Sort-Id  and  by  Equation  7.67  in  u,  {SIMULATES,  [C.Name],  [c])  = 
{SIMULATES,  [C.Name],  [c])  =  o  G  S'  .Operations. 

(d)  If  the  source  of  o  G  S.Operations  is  Equation  7.50  then  o  =  {A.Name,  dom,  [Boolean]) 
where  dom  =  [c.IVame  |  c  G  A.Connection].  By  OMT-46,  for  each  c  G  A.Connection, 
there  must  be  an  operation  {IMAGE,  [A.Name,  c.Name],  [c2.Name-CLASS])  G 
^Operation.  Then,  by  w  Equation  7.69,  the  second  sort  in  each  IMAGE  operation 
in  A,  Range-Ident{2)  (which  equals  c.Name  for  some  c  G  C.Connection)  becomes  part 
of  the  domain,  dom,  of  the  operation  {A.Name,  dom,  [BooZean])  =  {A.Name,  dom, 
[BooZean])=  o  G  S'  .Operations. 
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Therefore,  since  for  each  possible  source  of  o  in  5  (Equations  7.41,  7.42,  7.48,  and  7.50), 
if  o  was  generated  by  that  equation  then  o  G  S.Operations  o'  G  S'  .Operations  and 
S.Operations  C  S'  .Operations. 

o  G  S'  .Operations  =»  o  G  S.Operations.  If  o  G  S'  .Operations,  there  are  five  possible 
sources  -  Equations  7.59,  7.60,  7.61,  7.67,  or  7.69.  Each  is  analyzed  below. 

(a)  If  the  source  of  o  G  S'  .Operations  is  Equation  7.59  then  there  must  be  some  attribute 
a  G  C.Attribute  such  that  a  =  o  =  {o.Name,  C:Name,  o.Range-Ident) .  The  only  r 
transformation  that  could  create  such  an  attribute  in  C  is  OMT-13.  Thus  by  OMT-13 
there  must  be  some  a'  in  C.Attribute  such  that  a'. Name  =  o.Name  and  [a' .Datatype]  = 
o.Range-Ident.  Therefore,  by  Equation  7.41  in  transformation  ip,  {a'. Name,  [C.Name], 
[a' .Datatype])  =  (o.Name,  [CiVame],  o.Range-Ident)  =  o  G  S.Operations. 

(b)  If  the  source  of  o  G  S'  .Operations  is  Equation  7.60  then  o  =  (o.Name,  [C.Name] 

o.Range-Ident)  G  C.Operation  and  o.Name  ATTR-EQU AL.  The  only  transfor¬ 

mation  that  creates  such  an  operation  in  C  from  Q  is  OMT-14.  Thus  by  OMT-14  there 
must  be  some  a  =(a.Name,  [C.Name],  [a.Datatype])  in  C.Attribute  such  that  a. Name 
=  o.Name  and  a.Datatype  —  o.Range-Ident.  Then,  by  Equation  7.41  in  ip,  (a.Name, 
[C.Name],  [a.Datatype])  =  (o.Name,  [CiVame],  o.Range-Ident)  =  o  G  S.Operations. 

(c)  If  the  source  of  o  G  S'  .Operations  is  Equation  7.61  then  o  =  (o.Name,  ^.Name,name] 
[Boolean])  G  S'q. Operations  and,  since  Equation  7.61  is  the  only  equation  in  w  capable 
of  producing  such  an  operation,  there  exists  an  attribute  a  G  ^.Attribute  such  that 
a.Range-Ident  =  [name-CLASS]  and,  by  the  definition  of  om-pred,  a.Name  =  xxx- 
OBJ  if  o.Name  =  HAS-PART  or  a.Name  =  o.Name  if  o.Name  ^  HAS-PART. 
Since  the  only  transformation  that  can  create  an  attribute  with  this  signature  in  C  from 
Q  is  OMT-5,  there  must  exist  some  c  G  C.Connection  such  that  c.Name  =  name  and 
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attr-name{c)  =  a.Name.  This  means  that  if  o.Name  =  HAS-PART  then  c.Role  is 
undefined,  otherwise  c.Role  =  a.Name  =  o.Name. 

Thus  by  Equation  7.42  in  tp, 

{comp-pred{c),  [C.Name,c.Name],  [Boolean])  =  {o.Name,  [S.Name,name],  [Boolean]) 
=  {o.Name,  [S'.Name,  name],  [Boolean])  =  o  E  Sc -Operations.  Therefore,  o  E 
S'  .Operations  =>  o  E  S.Operations  for  operations  in  S'  generated  by  Equation  7.61. 

(d)  If  the  source  of  o  £  S'  .Operations  is  Equation  7.67  then  o  =  {SIMULATES,  [CA^ame], 
[c])  and  c  must  be  a  sort  in  C.Class-Sort.Inherited-Sort-Id.  Since  OMT-4  is  the  only 
transformation  that  generates  sorts  in  C..Class-Sort.Inherited-Sort-Id,  it  must  be  the 
case  that  c  is  in  C. Superclass  and  thus,  by  (f  Equation  7.48,  {SIMULATES,  [C.Name], 
[c])  =  {SIMULATES,  [CiVame],  [c])  =  o  E  S.Operations. 

(e)  Finally,  if  the  source  of  o  €  S' .Operations  is  Equation  7.69  then  o  =  ([A.A/’ome],  dom, 
[Boolean])  where  each  sort  name,  s  E  dom,  must  be  o.Domain-Ident{2)  in  some  oper¬ 
ation  named  IMAGE  in  A.Operation.  Since  OMT-46  is  the  only  transformation  in  r 
capable  of  placing  an  IMAGE  operation  in  A.Operation  and  (OMT-49  defines  qualified 
operations  that,  by  assumption,  are  not  included  in  5),  5  must  be  the  name  of  some 
connection,  c,  in  A  and  thus  s  =  c.Name.  Then  by  Equation  7.50,  {[A.Name],  dam, 
[Boolean])  =  ([A.iVome],  dom,  [Boolean])  =  o  £  S.Operations. 

Therefore,  since  for  each  possible  source  of  o  in  S'  (Equations  7.59,  7.60,  7.61,  7.67,  and 
7.50),  if  o  was  generated  by  that  equation  then  o  £  S'  .Operations  =>■  o  £  S.Operations 
and  S'  .Operations  C  S.Operations.  Also,  since  I  already  established  that  S.Operations  C 
S'  .Operations,  it  must  be  the  case  that  S.Operations  =  S'  .Operations. 

5.  Axioms 

Initially,  the  number  of  transformations  equations  in  (p  (7.43,  7.44,  7.45,  7.46,  7.47,  7.51, 
7.52,  7.53,  7.54,  and  7.55)  along  with  the  number  of  transformations  equations  in  w  (  7.62, 
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7.63,  7.64,  7.65,  7.66,  7.70,  7.71,  7.72,  7.73,  and  7.74)  make  it  appear  though  proving  that 
the  axioms  generated  by  one  equation  are  unique  and  can  only  be  transformed  into  an  exact 
duplicate  might  be  exhausting  if  not  impossible;  however,  by  making  a  few  observations  the 
proof  can  be  dramatically  simplified. 

First,  note  that  the  axioms  generated  by  classes  by  equations  7.43-  7.47  and  7.62  -  7.66  are 
unique  from  those  generated  for  associations  by  equations  7.51  -  7.55  and  7.70  -  7.74.  All 
class  axioms  are  based  on  a  predicate  in  the  class  whose  name  is  determined  by  the  functions 
comp-pred  or  om-pred.  The  resulting  predicate  name  is  either  HAS-PART  or  the  role  name 
of  the  component  class.  However,  in  an  association,  the  name  of  the  predicate  is  the  name 
of  the  association.  Therefore,  assuming  unique  names  in  the  object  model,  fp  and  ui  generate 
unique  axioms  in  Sc  and  Sa- 

Second,  note  that  inside  a  given  class  or  association,  the  axioms  generated  by  separate  rules 
are  unique  with  a  few  minor,  non-critical  exceptions.  For  example,  in  the  set  of  equations 
7.43-  7.47,  Equation  7.43  generates  the  axiom 

“X  €  c.Name  ^  SIZE{{Y  \  comp-pred{c){X,Y)})  =  1” 

that  may  also  be  generated  by  Equation  7.47.  This  is  because  the  same  OMT  notation  can  be 
represented  in  two  ways  in  the  generic  OMT  abstract  syntax  tree.  This  is  not  a  problem  since 
both  representations  result  in  the  same  axioms  being  generated.  Also,  the  axiom  generated 
by  Equation  7.44  may  also  be  generated  by  Equation  7.45  while  the  axiom  generated  by 
Equation  7.46  may  also  be  generated  by  Equation  7.47.  In  both  these  cases,  there  are  two 
distinct  methods  of  representing  the  same  semantics  in  the  OMT  object  model;  however,  both 
representations  generate  the  exact  same  axiom.  Since  I  am  only  concerned  about  preserving 
the  semantics  of  the  object  model,  the  internal  representation  in  the  generic  OMT  AST  is  of 
no  importance  as  long  as  the  semantics  are  equivalent. 


F-9 


I  first  look  at  an  axiom  a  in  a  class  Sc  followed  by  axioms  in  an  association  Sa- 
Aggregate  Axioms. 

a  e  S. Axioms  =»  a'  €  S'. Axioms.  Since  a  is  in  a  class,  it  must  have  been  generated  by 

one  of  the  Equations  7.43  -  7.47.  Each  possibility  is  discussed  below. 

(a)  If  a  in  Sc -Axioms  is  of  the  form  generated  by  Equation  7.43  such  that 
a  =“A  e  s  SIZE{{Y  \  p(X,F)})  =  1” 

then  there  exists  a  c  G  C.Connection  such  that  (1)  by  Equation  7.43,  c.Mult  —  One, 
c.Name  =  s,  and  if  p  =  HAS-PART  then  c.Role  =  undefined  else  c.Role  =  p,  or  (2) 
by  Equation  7.47  c.Mult  =  Specified,  c.Name  =  s,  ifp  =  HAS-PART  then  c.Role  — 
undefined  else  c.Role  =  p,  and  c.Specified  —  {{1,  unde  fined)}. 

i.  If  c.Mult  =  One,  then  by  OMT-8  there  exists  an  axiom  axi  £  C.Axiom  such  that 

axi  =“SIZE{IMAGE{attr-nameic){X),Q))  =  1” 
where  attr-name{c)  =  c.Role  (if  defined)  or  c.Name-C LAS S . 

ii.  If  c.Mult  =  Specified,  then  by  OMT-12  there  exists  an  axiom  ax2  S  C.Axiom  such 
that 

ax2  =‘'SIZE{IMAGE{attr-name{c){X),Q))  =  s.valuel” 

Thus  it  is  obvious  that  axi  =  0x2  =  ax  G  C.Axiom.  From  here,  there  are  two  paths  to 
S'q,  via  Equation  7.62  or  7.66. 

i.  Given  ax,  by  Equation  7.62  there  exists  an  axiom  a'l  G  S'q. Axioms  such  that 

a'l  =“X  G  30rt-of{attr-name{c)) 

SIZE{{Y  I  om-pred{attr-name{c)){X,Y)})  =  1” 

where  if  c.Role  was  defined  then  sort-of{attr-name{c))  =  sort-of  (c.Role)  =  c.Name 
=  s  (by  OMT-5)  and  om-pred(attr-name(c))  =  om-pred(c.Role)  =  c.Role  =  p,  or 
if  c.Role  was  not  defined  then  sort-of(attr-name(c))  =  sort-of  (c. Name-0 BJ)  = 
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c.Name  =  s  (by  OMT-5)  and  om-pred{attr-name{c))  —  om-pred{c.Name-OBJ)  — 
HAS-PART  =  p.  Thus  a  =  a[. 

ii.  Given  ax,  by  Equation  7.66  there  exists  an  axioms  G  S'q. Axioms  such  that 

a'2  €  sort-of{attr-name{c)) 

=>  SIZE({Y  I  oTn-pred{attr-name{c)){X,Y)})  =  s.valueV’ 

where  s.valuel  =  1,  and  if  c.Role  was  defined,  sort-of{attr-name{c))  =  sort- 
of{c.Role)  =  c.Name  =  s  (by  OMT-5)  and  om-pred{attr-name{c))  —  om- 
pred{c.Role)  =  c.Role  =  p,  or  if  c.Role  was  not  defined  then  sort-of{attr-name{c)) 
=  sort-of{c.Name-OBJ)  —  c.Name  =  s  (by  OMT-5)  and  om-pred{attr-name{c)) 
=  om-pred{c.Name-OBJ)  =  HAS-PART  =  p.  Thus  a  =  a'^. 

Again  it  is  clear  that  a'l  =  a'^—  a  and  thus  any  axiom  in  Sc  generated  by  Equation  7.43 
(or  by  Equation  7.47  in  the  form  of  Equation  7.43)  also  exists  in  S'q. 

(b)  If  a  in  Sc -Axioms  is  of  the  form  generated  by  Equation  7.44  such  that 
a  =“X  €  s  SIZE{{Y  \  p(X,y)})  >  0” 

then  there  exists  ace  C.Connection  such  that  (1)  by  Equation  7.44,  c.Mult  =  Many, 
c.Name  =  s,  and  if  p  =  HAS-PART  then  c.Role  =  undefined  else  c.Role  =  p,  or 
(2)  by  Equation  7.45,  c.Mult  —  Plus,  c.Name  =  s,\ip  =  HAS-PART  then  c.Role  = 
undefined  else  c.Role  =  p,  and  c.Plus.Integer  =  0. 

i.  If  c.Mult  =  Many,  then  by  OMT-9  there  exists  an  axiom  axi  e  C. Axiom  such  that 

axi  =“SIZE{IMAGE{attr-name{c){X),Q))  >  0” 
where  attr-name(c)  =  c.Role  (if  defined)  or  c.Name-C LAS S . 

ii.  If  c.Mult  =  Plus,  then  by  OMT-10  there  exists  an  axiom  ax2  €  C.Axiom  such  that 

ax2  =“SIZE{IMAGE{attr-name{c){X),Q))  >  c.Plus.Integer" 

Thus  it  is  obvious  that  axi  =  ax^  =  ax  G  C.Axiom.  Then  by  Equation  7.63  there  exists 
an  axiom  a'l  G  S'q. Axioms  such  that 
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a'l  —“X  e  aort-of{attr-name{c)) 

^  SIZB{{Y  I  om-pred{attr-name{c)){X,Y)})  >  0” 

where  if  c.Role  was  defined  then  sort-of{attr-name{c))  =  sort-of{c.Role)  =  c.Name  = 
s  (by  OMT-5)  and  om-pred(attr-name(c))  —  om-pred{c.Role)  —  c.Role  =  p,  or  if  c.Role 
was  not  defined  then  sort-of(attr-name{c))  =  sort-of{c.Name-OBJ)  =  c.Name  =  s 
(by  OMT-5)  and  om-pred{attr-name{c))  =  om-pred{c.Name-OB  J)  =  HAS-PART  = 

р.  Thus  a  =  a'l. 

Again  it  is  clear  that  a'l  =  a'2  =  a  and  thus  any  axiom  in  Sc  generated  by  Equation  7.44 
(or  by  Equation  7.45  in  the  same  form)  also  exists  in  S'q. 

(c)  If  a  in  Sc -Axioms  is  of  the  form  generated  by  Equation  7.45  such  that 
a  =“A  €  s  =►  SIZE{{Y  \  p{X,Y)})  >  x” 

then  by  Equation  7.45  there  exists  a  c  €  C. Connection  such  that  c.Mult  =  Plus,  c.Name 
=  5,  if  p  =  HAS-PART  then  c.Role  =  undefined  else  c.Role  =  p,  c.Plus. Integer  =  x. 
(Note:  If  X  =  0  then  a  is  of  the  form  generated  by  Equation  7.44  that  was  previously 
shown  to  be  in  OM';  therefore,  in  this  section  of  the  proof,  I  assume  x  >  0.) 

Then  by  OMT-10  there  exists  an  axiom  ax  e  C.Axiom  of  the  form 
ax  =“SIZE(IMAGE(attr-name(c)(X),Q))  >  c.Plus. Integer” 
and  by  Equation  7.64  there  exists  an  axiom  a'  €  S'(^. Axioms  such  that 

o'  =“X  G  sort-of{aitr-name{c)) 

=>  SIZE{{Y  I  om-pred{attr-name{c)){X,Y)})  >  c.Plus. Integer” 

where  c.Plus. Integer  =  x,  if  c.Role  was  defined,  sort-of{attr-name{c))  =  sort- 
of  {c.Role)  =  c.Name  =  s  (by  OMT-5)  and  om-pred{attr-name{c))  =  om-pred{c.Role)  = 

с. Role  =  p,  or  if  c.Role  was  not  defined  then  sort-of{attr-name{c))  =  sort-of{c.Name- 
OBJ)  =  c.Name  =  s  (by  OMT-5)  and  om-pred{attr-name{c))  —  om-pred{c.Name- 
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OBJ)  =  HAS-PART  =  p.  Thus  a  =  a'  and  thus  any  axiom  in  Sc  generated  by 
Equation  7.45  also  exists  in  Sq. 

(d)  If  a  in  Sc -Axioms  is  of  the  form  generated  by  Equation  7.46  such  that 
a  =“X  6  s  {SIZE{{Y  I  piX,Y)})  =  0  V  SIZEi{Y  \  ij(X,y)})  =  1)” 
then  there  exists  ace  C. Connection  such  that  (1)  by  Equation  7.46,  c.Mult  =  Optional, 
c.Name  =  s,  and  ii  p  =  HAS-PART  then  c.Role  =  undefined  else  c.Role  =  p,  or  (2) 
by  Equation  7.47,  c.Mult  =  Specified,  c.Name  =  s,  if  p  =  HAS-PART  then  c.Role  = 
undefined  else  c.Role  =  p,  and  c.Specified  =  {sri,  5r2},  sri  =  (0,  undefined),  and  sr2 
=  {1,  unde  fined). 

i.  If  c.Mult  =  Optional,  then  by  OMT-ll  there  exists  an  axiom  axx  €  C.Axiom  such 
that 

ax2  ='^SIZE{IMAGE{attr-name{c){X),Q))  =  0 
V  SIZE{IMAGE{attr-name{c){X),Q))  =  1” 

where  attr-name{c)  =  c.Role  (if  defined)  or  c.Name-CLASS. 

ii.  If  c.Mult  =  Specified,  then  by  OMT-12  there  exists  an  axiom  ax2  £  C.Axiom  such 
that 

ax2  =“SIZE{IMAGE{attr-name{c){X),Q))  =  srx.valuel 
V  SIZE{IMAGE{attr-name{c){X),Q))  =  sr2.value2” 

where  s.valuel  =  0  and  s.value2  =  1. 

Thus  it  is  obvious  that  axi  =  ax2  =  ax  e  C.Axiom.  Prom  here,  there  are  two  paths  to 
Sq,  via  Equation  7.65  or  7.66. 

i.  Given  ax,  by  Equation  7.65  there  exists  an  axiom  a'l  £  S'q. Axioms  such  that 
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a'l  =“X  €  sort-of{attr-natne{c)) 

=>  {SIZE{{Y  I  om-pred{attr-name(c)){X,Y)Y)  =  0 
V  SIZE({Y  I  oni-pred(attr-name{c)){X,Y)})  =  1)” 

where  if  c.Role  was  defined  then  sort-of(attr-name{c))  =  soTt-of{c.Role)  =  c.Name 
=  s  (by  OMT-5)  and  om-pred{aUr-name{c))  =  om-pred{c.Role)  =  c.Role  =  p,  or 
if  c.Role  was  not  defined  then  sort-of{attr-name{c))  =  sart-of  {c.N ame-OB  J)  = 
c.Name  =  s  (by  OMT-5)  and  om-pred(attr-name{c))  =  cm-pred{c.Name-OBJ)  = 
HAS-PART  =  p.  Thus  a  =  a^. 

ii.  Given  ax,  by  Equation  7.66  there  exists  an  axioms  £  S'q. Axioms  such  that 

a'2  =“X  e  sort-of(aUr-name(c)) 

(SIZE{{Y  I  om-pred{attr-name{c)){X,Y)})  =  s.valuel 
V  SIZE{{Y  I  om-pred{attr-name{c)){X,Y)})  =  s.value2)” 

where  s.valuel  =  0,  s.value2  =  1,  and  if  c.Role  was  defined,  sort-of{aUr-name{c)) 
=  sort-of  (c.Role)  =  c.Name  =  s  (by  OMT-5)  and  om-pred(attr-name(c))  =  om- 
pred(c.Role)  =  c.Role  —  p,  or  if  c.Role  was  not  defined  then  sort-of  (attr-name{c)) 
=  sort-of  (c.N  ame-OB  J)  =  c.Name  ~  s  (by  OMT-5)  and  om-pred(attr-name(c)) 
=  om-pred(c.N  ame-OB  J)  =  HAS-PART  —  p.  Thus  a  =  a^. 

Again  it  is  clear  that  a'j  =  a'2  =  a  and  thus  any  axiom  in  Sc  generated  by  Equation  7.46 
also  exists  in  S'c- 

(e)  If  a  £  Sc -Axioms  consists  of  the  logical  disjunction  of  n  subaxioms  of  either  of  two 
forms 

“A  £  s  =>  SIZE({Y  I  p(A,y)})  =  vi” 
or 

“X  €  s  =>  (SIZE({Y  i  p(X,y)})  >  vi  V  SIZE({Y  \  p(X,Y)})  <  V2)" 
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and  assuming  a  is  not  of  the  form  generated  by  Equations  7.43  or  7.46,  then  by  Equa¬ 
tion  7.47  there  exists  c  G  C.Connection  such  that  c.Mult  —  Specified,  c.Name  =  s, 
and  c.Role  =  p\ip  ^  HAS-PART. 


Then  for  each  subaxiom  ai...a„  in  a,  there  exists  some  s  G  c. Specified  (where  s  is  of 
type  SPEC-RANGE)  such  that  s.valuel  =  vi  and  s.value2  =  V2- 
Then  by  OMT-12  there  exists  an  axiom  ax  G  C.Axiom  where  ax  is  the  logical  disjunction 
of  the  set  of  subaxioms  generated  for  each  Si  G  c.Specified  such  that 
Si  =“SIZE(attr-naTne{c){X))  =  s.valueV’ 


or 


Si  =“(SIZE{attr-name{c)(X))  >  s.valuel 
V  SIZE{attr-name{c){X))  <  s.value2y’ 

where  attr-name{c)  =  c.Role,  if  defined,  or  c.Name  otherwise. 

Then  by  Equation  7.66  there  exists  an  a'  in  Sq. Axioms  such  that  for  each  subaxiom  of 
ax  of  one  of  the  forms  given  above  for  s,  there  exists  a  subaxiom  in  o'  of  the  form 

‘X  G  sort-of{attr-name{c)) 

=>  SIZE{{Y  I  om-pred{attr-name{c)){X,Y)})  =  s.valuel" 


or 


“X  G  sort-of{attr-name(c))  {SIZE{{Y  \  om-pred{attr-name{c)){X,Y)})  >  s.valuel 
V  SIZE{{Y  I  om-pred{attr-name{c)){X,Y)})  <  s.value2)” 

where  if  c.Role  is  defined  then  sort-of{attr-name{c))  =  sort-of  (c.Role)  =  c.Name  = 
s  and  om-pred(aUr-name(c))  =  om-pred(c.Role)  =  c.Role  =  p.  And,  if  c.Role  is  not 
defined,  then  sort-of(attr-name{c))  =  sort-of{c.Name-OBJ)  =  c.Name  =  s  and  om- 
pred(attr-name{c))  =  om-pred{c.Name-OBJ)  =  HAS-PART  =  p.  Therefore,  each 
subaxiom  in  o'  G  S'q. Axioms  is  of  the  form 

“X  G  s  =4^  SIZE({Y  1  p(X,y)})  =  vi” 
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or 

“X  e  s  {SIZE{{Y  I  p(x,y)})  >  Wi  V  size{{y  I  p(x,y)})  <  ^2)” 
and  thus  for  each  subaxiom  in  a  there  exists  an  equivalent  subaxiom  in  o'  and  thus  a  = 
a'. 

Therefore,  since  for  each  type  of  axiom  in  Sc-Axioms  there  is  an  equivalent  axiom  in 
Sq. Axiom  then  Sc-Axioms  C  Sq. Axioms. 

a  £  S'. Axioms  ^  o  €  S. Axioms.  The  six  possible  sources  of  axioms  in  S'^  are  analyzed 

below. 

(a)  If  a  in  S^. Axioms  is  of  the  form  generated  by  Equation  7.62  such  that 
a  =“X  e  s  =>  SIZE({Y  I  p(X,  Y)})  =  1” 
then  there  exists  an  axiom,  ax  €  C.Axiom  of  the  form 
ax  ='‘SIZEiIMAGE{n(X),Q))  =  1” 

generated  by  either  Equation  7.62  or  7.66  where  sort-of{n)  =  s  and  om-pred{n)  =  p. 
Given  ax,  there  are  two  paths  from  C,  OMT-8  or  OMT-12. 

i.  If  ax  is  generated  by  OMT-8  then 

A.  If  c.Role  is  defined  then  there  exists  a  c  E  C.Connection  such  that 

c.Mvlt  =  ONE 
n  =  attr-name{c)  =  c.Role 
s  =  sort-of{n)  =  sort-{c.Role)  =  c.Name 
p  =  om-pred{n)  =  om-pred{c.Role)  =  c.Role 
comp-pred{c)  =  c.Role  =  p 

Thus  by  Equation  7.43  there  exists  an  axiom  a'^  E  Sc -Axiom  such  that 

a'l  =  “X  e  c.Name  ^  SIZE{{Y  \  comp-pred{c)(X,  T)})  =  1” 

=  “X  E  s  SIZE{{Y  1  p(X,  Y)})  =  1” 

B.  If  c.Role  is  not  defined  then  there  exists  a  c  E  C.Connection  such  that 
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c.Mult  =  ONE 

n  =  attr-name{c)  =  c.Name  —  OBJ 
s  =  3ort-of{n)  =  sort-(c.Name-OBJ)  =  c.Name 
p  =  om-pred{n)  =  om-pred{c.Name-OBJ)  =  H  AS-P  ART 
comp-pred{c)  =  H  AS-P  ART  =  p 

Thus  by  Equation  7.43  there  exists  an  axiom  £  Sc -Axiom  such  that 

a'a  =  “X  €  c.Name  ^  SIZE({Y  \  comp-pred{c){X,  F)})  =  1” 

=  “xes=!^  siZE{{Y  I  p{x,  y)})  =  i” 

Thus  a'l  =  02  e  Sc -Axioms  =  a  €  S'^ -Axioms. 
ii.  If  ax  is  generated  by  OMT-12 

A.  If  c.Role  is  defined  then  there  exists  a  c  £  C.Connection  such  that 

c.Mult  =  Specified 
c.Mult  =  {{1,  undefined)} 
n  =  attr-name(c)  =  c.Role 
a  =  sort-of{n)  =  sort-{c.Role)  =  c.Name 
p  =  om-pred{n)  =  om-pred{c.Role)  =  c.Role 
comp-pred{c)  =  c.Role  —  p 

Thus  by  Equation  7.47  there  exists  an  axiom  a'l  G  Sc -Axiom  such  that 
a'l  =  '‘'X  ^  c.Name  ^  SIZE{{Y  \  comp-pred{c){X,Y)})  =  x.valueV' 

=  “X  e  s  =►  siZE{{Y  I  p{x,  y)})  =  i” 

B.  If  c.Role  is  not  defined  then  there  exists  a  c  £  C.Connection  such  that 

c.Mult  =  Specified 

c.Mult  =  {{1,  undefined)} 

n  =  attr-name{c)  =  c.Name  —  OBJ 

a  =  aort-of{n)  =  aort-{c.Name-OBJ)  =  c.Name 

p  =  om-predln)  —  om-pred{c.Name-OBJ)  =  H  AS-P  ART 

comp-pTed{c)  =  H  AS-P  ART  =  p 

Thus  by  Equation  7.47  there  exists  an  axiom  £  Sc -Axiom  such  that 
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02  =  “jy  e  c.Name  =>•  SIZE{{Y  \  comp-pred{c){X,Y)];)  —  x.valuel" 

=  “X  e  s  sizE{{Y  I  p(x,  y)})  =  1” 

Thus  a'l  =  a'2  £  Sc-Axioms  =  a  £  S'Q.Axioms. 

Again  it  is  clear  that  ai  =  a2  =  a  and  thus  any  axiom  in  S'q  generated  by  Equation  7.62 
also  exists  in  Sc- 

(b)  If  a  in  S'^. Axioms  is  of  the  form  generated  by  Equation  7.63  such  that 
a=“X  £s=^  SIZE({Y  \  p{X,  F)})  >  0” 

then  there  exists  an  axiom,  ax  £  C.Axiom  of  the  form 
ax  =‘^SIZE{IMAGE{n{X),Q))  >  0” 

generated  by  Equation  7.63  where  sort-of(n)  =  s  and  om-pred{n)  =  p. 

Given  ax,  there  are  two  paths  from  C,  OMT-9  or  OMT-10. 

i.  If  ax  is  generated  by  OMT-9  then 

A.  If  c.Role  is  defined  then  there  exists  a  c  £  C.Connection  such  that 

c.Mult  —  Many 
n  =  attr-name{c)  =  c.Role 
s  =  sort-of{n)  =  sort-{c.Role)  =  c.Name 
p  =  om-pred{n)  =  om-pred{c.Role)  =  c.Role 
comp-pred{c)  =  c.Role  =  p 

Thus  by  Equation  7.44  there  exists  an  axiom  a[  £  Sc -Axiom  such  that 

a'l  =  “X  £  c.Name SIZE{{Y  \  comp-pTed(c){X,Y)Y)  yOi" 

=  “X  £  s  ^  SIZE{{Y  I  p{X,  y)})  >  0” 

B.  If  c.Role  is  not  defined  then  there  exists  a  c  £  C.Connection  such  that 
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c.Mult  =  Many 

n  =  attr-name(c)  =  c.Name  —  OBJ 
3  =  sort-ofin)  =  sort-{c.Name-OBJ)  =  c.Name 
p  =  om-pred{n)  =  om-pred{c.Name-OBJ)  =  HAS-PART 
comp-pred{c)  =  HAS-PART  =  p 

Thus  by  Equation  7.44  there  exists  an  axiom  6  Sc -Axiom  such  that 

a'a  =  “X  €  c.Name  ^  SIZE{{Y  \  comp-pred{c)(X,  F)})  >  0” 

=  "X  es^  SIZE{{Y  I  p{X,  F)})  >  0” 

Thus  a'l  =  G  Sc -Axioms  =  a  6  S'^- Axioms. 
ii.  If  ax  is  generated  by  OMT-10 

A.  If  c.Role  is  defined  then  there  exists  ace  C.Connection  such  that 

c.Mult  —  Plus 

c.  Plus. integer  =  0 

n  =  attr-name{c)  =  c.Role 

s  =  soTt-of{n)  =  sort-{c.Role)  =  c.Name 

p  =  om-pred{n)  =  om-pred{c.Role)  =  c.Role 

comp-pred{c)  =  c.Role  =  p 

Thus  by  Equation  7.45  there  exists  an  axiom  a[  e  Sc -Axiom  such  that 

a'l  =  “X  e  c.Name  ^  SIZE{{Y  |  comp-pred{c){X,Yy))  >  x. Plus. integer” 
=  “X  e  s  SIZE{{Y  I  p{X,  F)})  >  0” 

B.  If  c.Role  is  not  defined  then  there  exists  a  c  E  C.Connection  such  that 

c.Mult  =  Plus 

c.Plus. integer  =  0 

n  =  attr-name{c)  =  c.Name  —  OBJ 

s  =  sort-of{n)  =  sort-{c.Name-OBJ)  =  c.Name 

p  =  om-pred{n)  =  om-pred{c.Name-OBJ)  =  HAS-PART 

comp-pred{c)  =  HAS-PART  =  p 

Thus  by  Equation  7.45  there  exists  an  axiom  6  Sc -Axiom  such  that 
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o!^  =  “X  &  c.Name  SIZE({Y  \  comp-pred(c){X,Y)})  >  c.Plus.integer” 

=  “X  6  s  =>  SIZE{{Y  I  p(X,  y)})  >  0” 

Thus  a'l  =  a2  S  Sc-Axioms  —  a  £  Sq. Axioms. 

Therefore,  it  is  clear  that  ai  =  a2  =  a  and  thus  any  axiom  in  S'q  generated  by  Equa¬ 
tion  7.62  also  exists  in  Sc- 

(c)  If  a  in  S'q. Axioms  is  of  the  form  generated  by  Equation  7.64  (assuming  x  >  0)  such  that 
a  =“X  €  a  =>  SIZE({Y  \  p(X,y)})  >  x” 

then  there  exists  an  axiom,  ax  6  C.Axiom  of  the  form 
ax  ='‘SIZE{IMAGE{n{X),Q))  >  x” 

generated  by  either  Equation  7.64  where  sort-of{n)  =  s  and  om-pred{n)  =  p. 

Given  ax,  by  OMT-10  there  exists  a  c  G  C.Connection  such  that 

i.  If  c.Role  is  defined  then 

c.Mult  =  Plus 

c.  Plus. integer  =  x 

n  —  attr-name{c)  —  c.Role 

s  =  sort-of{n)  =  sort-{c.Role)  =  c.Name 

p  =  om-pred{n)  =  om-pred{c.Role)  —  c.Role 

comp-pred{c)  =  c.Role  =  p 

Thus  by  Equation  7.45  there  exists  an  axiom  a'j  G  Sc -Axiom  such  that 

tt'i  =  “X  G  c.Name  SIZE{{Y  \  comp-pred{c){X,Y)})  >  c.Plus.integer" 

=  “X  €  a  ^  SIZE{{Y  I  p{X,  T)})  >  x” 

ii.  If  c.Role  is  not  defined  then 
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c.Mult  =  PLUS 

c.Plus. integer  =  x 

n  =  attr-name{c)  =  c.Name  —  OBJ 

a  =  3ort-of(n)  =  sort-(c.Natne-OBJ)  =  c.Name 

p  =  om-pred{n)  =  om-pred(c.Name-OBJ)  =  HAS-PART 

comp-pred{c)  —  HAS-PART  =  p 

Thus  by  Equation  7.45  there  exists  an  axiom  a'^  G  Sc -Axiom  such  that 

a'2  =  ‘'X  €  c.Name  =>  SIZE{{Y  \  comp-pred{c)(X,Y)})  >  c.Plus. integer” 

=  “X  €  s  =>  SIZE({Y  I  p{X,  y)})  >  x” 


Thus  a'j  =z  &  Sc.Axioms  =  a  G  S'Q.Axioms. 

Again  it  is  clear  that  ai  =  02  =  a  and  thus  any  axiom  in  Sq  generated  by  Equation  7.64 
also  exists  in  Sc- 

(d)  If  a  in  S'q. Axioms  is  of  the  form  generated  by  Equation  7.65  such  that 
a  =“X  €  s  ^  {SIZE{{Y  1  p{X,  T)})  =  0  V  SIZE{{Y  \  p{X,  T)})  =  1)” 

then  there  exists  an  axiom,  ax  G  C.Axiom  of  the  form 

ax  =“SIZE{IMAGE{n{X),Q))  =  0  V  SIZE{IMAGE{n{X),  Q))  =  1” 

generated  by  either  Equation  7.65  or  7.66  where  sort-of{n)  =  s  and  om-pred{n)  =  p. 
Given  ax,  there  are  two  paths  from  C,  OMT-11  or  OMT-12. 

i.  If  ax  is  generated  by  OMT-11  then 

A.  If  c.Role  is  defined  then  there  exists  a  c  G  C-Connection  such  that 

c.Mult  =  Optional 
n  =  attr-name{c)  =  c.Role 
a  =  aort-of{n)  =  sort-{c.Role)  =  c.Name 
p  =  om-pred(n)  =  om-pred{c.Role)  =  c.Role 
comp-pred{c)  =  c.Role  =  p 

Thus  by  Equation  7.46  there  exists  an  axiom  a\  G  Sc -Axiom  such  that 


F-21 


a'l  =  “X  €c.Name=^{SIZE{{Y\comp-pred{c){X,Y)})  =  0 
V  SIZE{{Y  I  comp-pred{c){X,Y)})  =  1)” 

=  “X  e  a  {SIZE{{Y  I  piX,  F)})  =  0  V  SIZE{{Y  \  piX,  F)})  =  1)” 

B.  If  c.Role  is  not  defined  then  there  exists  a  c  £  C.Connection  such  that 

c.Mult  =  Specified 

n  =  attr-name{c)  =  c.Name  —  OBJ 

3  =  sort-of(n)  =  sort-(c.Name-OB  J)  =  c.Name 

p  =  om-pred(n)  =  om-pred(c.Name-OBJ)  =  HAS-PART 

comp-pred{c)  =  HAS-PART  =  p 

Thus  by  Equation  7.46  there  exists  an  axiom  Oj  £  Sc -Axiom  such  that 

^2  =  “X  €  c.Name  =>•  SJZE{{Y  |  comp-pred{c){X,Y)})  =  1” 

=  “Xes=>  SIZE{{Y  I  p{X,  F)})  =  1” 

Thus  a'l  =  02  €  Sc -Axioms  =  a  £  S'q.  Axioms. 
ii.  If  ax  is  generated  by  OMT-12 

A.  If  c.Role  is  defined  then  there  exists  a  c  £  C.Connection  such  that 

c.Mult  =  Specified 

c.Mult  =  {{0,  undefined),  {1,  undefined)} 
n  =  attr-name{c)  =  c.Role 
3  =  3ort-of{n)  =  3ort-{c.Role)  =  c.Name 
p  =  om-pred{n)  =  om-pred{c.Role)  =  c.Role 
comp-pred(c)  =  c.Role  =  p 

Thus  by  Equation  7.47  there  exists  an  axiom  a'j  £  Sc -Axiom  such  that 

a'l  =  “X  €  c.Name  =»  SIZE{{Y  \  comp-pred{c){X,Y)})  =  x.valuel” 

=  “A  £  s  SIZE{{Y  I  p{X,  F)})  =  1” 

B.  If  c.Role  is  not  defined  then  there  exists  a  c  £  C.Connection  such  that 
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c.Mult  =  Specified 

c.Mult  =  {(0,  undefined),  (1,  undefined)} 
n  =  attr-name{c)  =  c.Name  —  OBJ 
s  =  sort-of{n)  =  sort-{c.Name-OBJ)  =  c.Name 
p  —  om-pred{n)  =  om-pred(c.Name-OBJ)  =  HAS-PART 
comp-pred(c)  =  HAS-PART  —  p 

Thus  by  Equation  7.47  there  exists  an  axiona  €  Sc-A.xiom  such  that 

ffl'i  =  “X  e  c.Name  SIZE({Y  \  comp-pred{c){X,Y)})  =  x.valuel” 

=  “Xes^  SIZE{{Y  I  piX,  Y)})  =  1” 

Thus  a[  =  a2  €  Sc-Axioms  =  a  6  S'Q.Axioms. 

Again  it  is  clear  that  ai  =  02  =  a  and  thus  any  axiom  in  5^  generated  by  Equation  7.65 
also  exists  in  Sc- 

(e)  If  a'  in  S'Q.Axioms  is  of  the  form  generated  by  Equation  7.66  such  that  it  consists  of 
the  logical  disjunction  of  n  subaxioms  of  either  of  two  forms 
“X  6  a  =>  SIZE{{Y  I  p(X,y)})  =  vi” 


or 


“X  G  s  =>  {SIZE{{Y  I  p(X,y)})  >  vi  V  SIZE{{Y  \  p(X,y)})  <  Vi)" 
and  assuming  a!  is  not  of  the  form  generated  by  Equations  7.62  or  7.65,  then  by  Equa¬ 
tion  7.66,  there  exists  an  axiom  ax  in  C.Axicm  where  ax  is  the  logical  disjunction  of 
the  set  of  subaxioms  generated  for  each  Sj  in  a'  such  that 

Si  =^SIZE{n{X))  =  vi" 


or 


Si  =“{SIZE{n{X))  >  vi  V  SIZE{n{X))  <  vi)" 
where  s  =  sort-of{n)  and  p  =  om-pred{c).  Then  by  OMT-12  there  exists  ace 
C. Connection  such  that  c.Mult  =  Specified,  there  exists  some  {vi,V2)  G  c.Specified 
(v2  may  be  undefined)  for  each  Si  in  ax,  and  the  attr-name(c)  =  n. 
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i.  By  the  definition  of  the  function  om-pred  in  Equation  7.75,  if  p  =  cm-pred{c)  = 
HAS-PARTS  then  c.Role  is  undefined  and 

n  =  attr-name{c)  —  c.Name  —  OBJ 
s  =  sort-of{n)  =  sort-of(c.Name-OBJ)  =  c.Name 
p  =  om-pred{n)  =  om-pred(c.Name-OBJ)  =  HAS-PART 
comp-pred{c)  =  HAS-PART  —  p 

ii.  By  the  definition  of  the  function  om-pred  in  Equation  7.75,  if  p  =  om-pred{c)  ^ 
HAS-PARTS  then  c.Role  is  defined  and 

n  =  attr-name{c)  =  c.Role 
s  =  sort-of{n)  =  sort-of  (c.Role)  —  c.Name 
p  =  om-pred(n)  =  om-pred{c.Role)  =  c.Role 
comp-pred(c)  —  c.Role  =  p 

Then  by  Equation  7.47  there  exists  an  a  in  Sc -Axioms  such  that  for  each  spec-range  e 
c.Specified  there  exists  a  subaxiom  in  a  of  the  form 

“X  6  sort-of  (attr-name(c)) 

^  SIZE({Y  I  om-pred{attr-name{c))(X,Y)})  =  s.valueV’ 


or 


“X  €  sort-of  (attr-name{c))  =>  {SIZE({Y  |  om-pred{attr-name(c))(X,Y)})  >  s.valuel 
V  SIZE({Y  I  om-pred{attr-name{c)){X,Y)})  <  s.valuei)” 

where  if  c.Role  is  defined  then  sort-of  (attr-name{c))  —  sort-of  (c.Role)  =  c.Name  = 
s  and  om-pred(attr-name(c))  =  om-pred(c.Role)  =  c.Role  =  p.  And,  if  c.Role  is  not 
defined,  then  sort-of  (attr-name(c))  =  sort-of  (c.Name-OBJ)  =  c.Name  =  s  and  om- 
pred(attr-name(c))  =  om-pred(c.Name-OBJ)  =  HAS-PART  =  p.  Therefore,  each 
subaxiom  in  a  €  Sc -Axioms  is  of  the  form 

“X  e  s  SIZE({Y  I  p(X,r)})  =  j;i” 
or 
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“Xes=^  {SiZE{{Y  I  p(x,y)})  >  «i  V  size{{y  \  p(x,y)})  <  ^2)” 
and  thus  for  each  subaxiom  in  a'  there  exists  an  equivalent  subaxiom  in  a  and  thus  a  = 
a'. 

Therefore,  since  for  each  type  of  axiom  in  S'^. Axioms  there  is  an  equivalent  axiom 
in  Sc-Axiom  then  S'Q.Axioms  C  Sc-Axioms,  and,  since  I  have  previously  shown  that 
Sc-Axioms  C  S'Q.Axioms,  it  is  clear  that  Sc-Axioms  =  S'Q.Axioms 

Association  Axioms.  Since  a  is  in  an  association  specification,  it  must  have  been 
generated  by  one  of  the  Equations  7.51  -  7.55.  Each  possibility  is  discussed  below. 

(a)  If  a  in  S a- Axioms  is  of  the  form  generated  by  Equation  7.51  such  that 
a  =“X  €  s  =►  SIZE{{Y  \  SA.Name{X,Y)})  =  1” 
then  there  exists  a  c  €  C. Connection  such  that  (1)  by  Equation  7.51,  c.Mult  =  One  and 
c.Name  =  s  ,  or  (2)  by  Equation  7.55  c.Mult  —  Specified,  c.Name  =  s,  c.Specified  = 
{sr},  and  sr  =(1, undefined). 

i.  If  c.Mult  =  One,  then  by  OMT-50  there  exists  an  axiom  axi  e  C.Axiom  such  that 

axi  =“A  e  c.Name  ^  SIZE{IMAGE{A,X))  =  1” 

ii.  If  c.Mult  =  Specified,  then  by  OMT-54  there  exists  an  axiom  ax2  S  C.Axiom  such 
that 

axi  =“A  6  c.Name  =>  SIZE{IMAGE{A,X))  =  sr.valuel” 

Thus,  since  sr.valuel  =  1,  axi  =  ax2  =  ax  €  <C.Axiom,  then  by  Equation  7.70  there 
exists  an  axiom  a'  €  S'Q.Axioms  such  that 

a'  =“A  e  c.Name  ^  SIZE({Y  \  S'A.Name{X,Y)})  =  1” 

Thus  a  =  a'  since  c.Name  =  s  and  SA-Name  =  S'Q.Name-,  therefore  any  axiom  in  Sa 
generated  by  Equation  7.51  (or  by  Equation  7.55  in  the  form  of  Equation  7.51)  also 
exists  in  S'q. 
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(b)  If  a  in  SA-Axioms  is  of  the  form  generated  by  Equation  7.52  such  that 

a  =“X  e  s  SIZE{{Y  I  SA.Name{X,Y)})  >  0” 
then  there  exists  a  c  €  C.Connection  such  that  (1)  by  Equation  7.52,  c.Mult  = 
Many  and  c.Name  =  s,  or  (2)  by  Equation  7.53,  c.Mult  =  Plus,  c.Name  =  s,  and 
c.Plus. Integer  =  0. 

i.  If  c.Mult  =  Many,  then  by  OMT-51  there  exists  an  axiom  axi  G  C.Axiom  such 
that 

axi  =“Z  €  c.Name  ^  SIZE{IMAGE{A,X))  >  0” 
where  attr-name(c)  =  c.Role  (if  defined)  or  c.Name-CLASS. 

ii.  If  c.Mult  =  Plus,  then  by  OMT-52  there  exists  an  axiom  ax2  6  C.Axiom  such  that 

axi  =“X  €  c.Name  ^  SI ZE{I M AGE{A, X))  >  c.Plus. integer” 

Thus,  since  c.Plus. Integer  =  0,  it  is  obvious  that  axi  =  ax2  =  ax  £  C.Axiom.  Then 
by  Equation  7.71  there  exists  an  axiom  a'  €  S'j^.Axioms  such  that 

a'  ='‘X  €  c.Name  =►  SIZE{{Y  \  S'A.Name{X,Y)})  >  c.Plus. integer” 
and  since  c.Name  =  s  and  SA-Name  =  S'^-Name,  a  =  o'  and  any  axiom  in  Sa  generated 
by  Equation  7.52  (or  by  Equation  7.53  in  the  same  form)  also  exists  in  S'^. 

(c)  If  a  in  S A- Axioms  is  of  the  form  generated  by  Equation  7.53  such  that 

a  =‘'X  e  s  =►  SIZE{{Y  I  SA.Name{X,Y)})  >  x” 
then  by  Equation  7.53  there  exists  a  c  G  C.Connection  such  that  c.Mult  =  Plus,  c.Name 
—  s,  and  c.Plus. Integer  =  x.  (Note;  If  x  =  0  then  a  is  of  the  form  generated  by 
Equation  7.52  that  was  previously  shown  to  be  in  OM';  therefore,  in  this  section  of  the 
proof,  I  assume  x  >  0.) 

Then  by  OMT-52  there  exists  an  axiom  ax  G  C.Axiom  of  the  form 
ax  =“X  G  c.Name  =>  SIZE{IMAGE{A,X)  >  c.Plus. Integer” 
and  thus  by  Equation  7.72  there  exists  an  axiom  a'  £  S a- Axioms  such  that 


F-26 


a'  =“X  e  c.Name  =>■  SIZE{{Y  \  S^.iVame(X,  F)})  >  c.Plus. Integer” 
and  since  c.Name  —  s,  c.Plus. Integer  =  x,  and  SA-Name  =  S\.Name,  it  must  be  true 
that  a  =  a'  and  thus  any  axiom  in  Sa  generated  by  Equation  7.53  also  exists  in  5^. 

(d)  If  a  in  S a- Axioms  is  of  the  form  generated  by  Equation  7.54  such  that 

a  =“X  e  a  =>  (SIZE{{Y  \  SA.Name{X,Y)})  =  0 
V  SIZE{{Y  I  SA.NameiX,Y)})  =  1)” 

then  there  exists  a  c  G  C.Connection  such  that  (1)  by  Equation  7.54,  c.Mult  =  Optional 
and  c.Name  =  s,  or  (2)  by  Equation  7.55,  c.Mult  =  Specified,  c.Name  =  s,  c.Specified 
=  {sri,  sr2},  sri  =  (0,  undefined),  and  sr2  =  {1,  unde  fined). 

i.  If  c.Mult  =  Optional,  then  by  OMT-53  there  exists  an  axiom  axi  G  C.Axiom  such 
that 

axi  =“X  G  c.Name  {SIZE{IMAGE{A,X)  =  0 
V  SIZE{IMAGE{A,X)  =  1)” 

ii.  If  c.Mult  =  Specified,  then  by  OMT-54  there  exists  an  axiom  ax2  G  C.Axiom  such 
that 

axi  =“X  G  c.Name  =>  {SIZE{IMAGE{A,X)  =  sri.valuel 
V  SIZE{IMAGE{A,X)  =  sri.valuel)” 

Thus  it  is  obvious  that  axi  =  ax2  =  ax  G  C. Axiom  and  by  Equation  7.73  there  exists 
an  axiom  a'  G  S'j^. Axioms  such  that 

a'  =“X  G  c.Name  =>  {SIZE{{Y  |  S'A.Name{X,Y)})  =  0 
V  SIZE{{Y  I  S'A-Name{X,Y)})  =  1)” 

and  since  c.Name  =  s  and  S'AName  =  SA-Name,  a  =  a'. 

Again  it  is  clear  that  a[  =  Uj  =  a  and  thus  any  axiom  in  Sa  generated  by  Equation  7.54 
also  exists  in  5^. 
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(e)  If  a  G  S A- Axioms  is  of  the  form  generated  by  Equation  7.55  such  that  a  consists  of  the 


logical  disjunction  of  n  subaxioms  of  either  of  two  forms 
“Z  G  s  ^  SIZE{{Y  I  pred{X,Y)})  =  vi” 
or 

^‘X  es=^  {SIZE{{Y  I  pTed{X,Y)})  >  vi  A  SIZE{{Y  |  p(X,y)})  <  vz)” 
and  assuming  a  is  not  of  the  form  generated  by  Equations  7.51  or  7.54,  then  by  Equa¬ 
tion  7.55  there  exists  c  G  C.Connection  such  that  c.Mult  =  Specified,  c.Name  =  s, 
and  pred  =  SA-Name. 

Then  for  each  subaxiom  oi...a„  in  a,  there  exists  some  s  G  c.Specified  (where  s  is  of  type 
SPEC-RANGE)  such  that  s.valuel  =  v\  and  s.value2  —  V2  {v2  may  be  undefined). 
Then  by  OMT-54  there  exists  an  axiom  ax  G  C.Axiom  such  that  ax  is  the  logical 
disjunction  of  the  set  of  subaxioms  generated  for  each  s,  G  c.Specified  such  that 
Si  =“X  €  c.Name  =►  SIZE{IMAGE{A,X))  =  s.valuel" 
or 

Si  ='X  G  c.Name  =►  {SIZE{IMAGE{A,X))  >  s.valuel 
A  SIZE(IMAGE{A,X))  <  s.value2)" 

Then  by  Equation  7.74  there  exists  an  a'  in  S'^^. Axioms  such  that  for  each  subaxiom  of 
ax  of  one  of  the  forms  given  above  for  Sj  there  exists  a  subaxiom  in  a'  of  the  form 
“X  G  c.Name  ^  SIZE{{Y  \  S'A.Name{X,Y)})  =  s.valuel" 
or 


“X  G  c.Name  =>  {SIZE{{Y  \  S'A.Name{X,Y)})  >  s.valuel 
A  SIZE{{Y  I  S'A.Name{X,Y)})  <  s.value2)" 

where  c.Name  =  s  and  S'j^.Name  =  SA-Name.  Therefore,  each  subaxiom  in  a'  G 
S'y^.Axioms  is  of  the  form 

“X  G  s  SIZE{{Y  I  pred{X,Y)})  =  vi" 
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or 

“X  e  s  (SIZE{{Y  I  prediX,Y)})  >  vi  V  SIZE{{Y  \  pred{X,Y)})  <  V2)” 
and  thus  for  each  subaxiom  in  a  there  exists  an  equivalent  subaxiom  in  a'  and  thus  a  — 
a'. 

Therefore,  since  for  each  type  of  axiom  in  S a- Axioms  there  is  an  equivalent  cixiom  in 
S'j^.Axiom  it  must  be  true  that  SA-Axioms  C  S'^.Axioms. 

a  e  S'. Axioms  =>•  a  €  S. Axioms.  The  six  possible  sources  of  axioms  in  S'^  are  analyzed 

below. 

(a)  If  a  in  S'^. Axioms  is  of  the  form  generated  by  Equation  7.70  such  that 
a  =‘X  es^  SIZE{{Y  I  5A.Arame(X,r)})  =  1” 
then  there  exists  an  axiom,  ax  €  C.Axiom  of  the  form 
ax  =‘X  €  sSIZE{IMAGE{A,X))  =  1” 
generated  by  either  Equation  7.70  or  7.74. 

Given  ax,  there  are  two  paths  from  C,  OMT-50  or  OMT-54. 

i.  If  ax  is  generated  by  OMT-50  then  c.Mult  =  ONE  and  c.Name  =  s,  and  by 
Equation  7.51  there  exists  an  axiom  a'j  e  SA-Axiom  such  that 
a'  =“X  e  c.Name  ^  SIZE{{Y  \  SA.Name{X,Y)})  =  1” 

Since  c.Name  —  s  and  SA-Name  =  S'^-Name,  a'  =  a. 
ii.  If  ax  is  generated  by  OMT-54  then  there  exists  ace  C.Ccmnection  such  that  c.Mult 
=  Specified,  c.Specified  =  {sr},  and  sr  =  {1,  unde  fined).  Thus  by  Equation  7.55 
there  exists  an  axiom  a'  e  SA-Axiom  such  that 

a'  =“X  6  c.Name  SIZE{{Y  \  SA.Name{X,Y)})  =  sr.valuel” 

Since  c.Name  =  s,  sr.valuel  =  1,  and  SA-Name  —  S^-Name,  a'  e  SA-Axioms  =  a  G 
S'A-Axioms  and  thus  any  axiom  in  generated  by  Equation  7.70  also  exists  in  Sa- 
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(b)  If  a  in  S'j^. Axioms  is  of  the  form  generated  by  Equation  7.71  such  that 

a  =“X  6  s  ^  SIZE{{Y  \  S'A.Name{X,Y)})  >  0” 
then  there  exists  an  axiom,  ax  G  Q.Axiom  of  the  form 
ax  =“X  e  sSIZE{IMAGE(A,X))  >  0” 
generated  by  Equation  7.71. 

Given  ax,  there  are  two  paths  from  C,  OMT-51  or  OMT-52. 

i.  If  ax  is  generated  by  OMT-51  then  there  exists  a  c  £  C.Connection  such  that  c.Mult 
=  Many  and  c.Name  =  s;  therefore,  by  Equation  7.52  there  exists  an  axiom  o'  £ 
S A- Axiom  such  that 

a  =“X  €  c.Name  =►  SIZE{{Y  \  SA.Name{X,Y)])  >  0” 

Therefore  since  a  =  c.Name  and  SA-Name  =  S'y^.Name,  o'  =  o. 
ii.  If  ax  is  generated  by  OMT-52  then  there  exists  a  c  £  C.Connection  such  that  c.Mult 
=  Plus,  c.Plus. integer  =  0,  and  s  —  c.Name  and  by  Equation  7.53  there  exists  an 
axiom  o'  €  S a- Axiom  such  that 

a  =“X  €  c.Name  ^  SIZE{{Y  \  SA.Name[X,Y)})  >  0” 

Since  s  =  c.Name  and  SA-Name  =  S'j^.Name,  o'  =  o;  therefore  any  axiom  in  S'^ 
generated  by  Equation  7.70  also  exists  in  Sa- 

(c)  If  o  in  S'j^.Axioms  is  of  the  form  generated  by  Equation  7.72  (assuming  x  >  0)  such  that 

a  =“X  e  s  ^  SIZE{{Y  I  S'A.Name{X,Y)))  >  x” 
then  there  is  an  axiom,  ax  £  C. Axiom 

X  eS=^  ax  =‘‘SIZE{JMAGE{A,X))  >  x” 
generated  by  Equation  7.72. 

Given  ax,  by  OMT-52  there  exists  a  c  £  C.Connection  such  th&tc.Mult  =  Plus, 
c.Plus. integer  =  x,  and  c.Name  =  s.  Therefore,  by  Equation  7.53  there  exists  an 
axiom  o'  £  S a. Axiom  such  that 
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a  =“X  €  c.Name  SIZE{{Y  \  SA-Natne(X,Y)})  >  c.Plus. integer'’ 

Again,  since  c.Plus. integer  =  x  and  c.Name  =  s,  it  is  clear  that  a  =  a  and  thus  any 
axiom  in  5^  generated  by  Equation  7.72  also  exists  in  Sa- 

(d)  If  a  in  S'^- Axioms  is  of  the  form  generated  by  Equation  7.73  such  that 

a  =^’X  es=^  {SIZE{{Y  I  S;i.Aame(A,y)})  =  0 
'^SIZE{{Y  I  S'A.Name{X,Y)))  =  1)” 

then  there  os  an  axiom,  ax  e  C.Axiom 

ax  =“X  e  s  =>  {SIZE(IMAGE{A,X))  =  0  V  SIZE{IMAGE{A,X))  =  1)” 
generated  by  either  Equation  7.73  or  7.74. 

Given  ax,  there  are  two  paths  from  C,  OMT-53  or  OMT-54. 

i.  If  ax  is  generated  by  OMT-53  then  there  exists  a  c  G  C. Connection  such  that  c.Mult 
=  Optional  and  c.Name  =  s.  Thus  by  Equation  7.54  there  exists  an  axiom  o'  G 
S A- Axiom  such  that 

a  =“A  G  c.Name  ^  {SIZE{{Y  \  SA.Name{X,Y)})  =  0 
WSIZE({Y  1  SA.NameiX,Y)})  =  1)” 

Therefore  since  s  =  c.Name  and  SA-Name  =  S^-Name,  a'  =  a. 
ii.  If  ax  is  generated  by  OMT-54  then  there  exists  a  c  G  C. Connection  such  thatc.Mult 
=  Specified,  c.Name  =  s,  c.Specified  =  {sri,  sr2},  sri  =  (0,  undefined),  and  sr2 
=  {1,  undefined). 

Thus  by  Equation  7.55  there  exists  an  axiom  o'  G  SA-Axiom  such  that 

a  =“A  G  c.Name  ^  iSIZE{{Y  \  SA.Name{X,Y)})  =  0 
WSIZEiiY  I  5>i.7Vome(X,y)})  =  1)” 

Therefore  since  s  =  c.Name  and  SA-Name  =  S'^-Name,  a'  =  a. 

Again  it  is  clear  that  o'  =  o  in  both  cases  and,  therefore,  any  axiom  in  5^  generated  by 
Equation  7.73  also  exists  in  Sa- 
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(e)  If  a'  in  S'j^. Axioms  is  of  the  form  generated  by  Equation  7.74  such  that  it  consists  of 
the  logical  disjunction  of  n  subaxioms  of  either  of  two  forms 
“X  SIZE{{Y  I  S'A-NameiX,  F)})  =  ?;i” 
or 

‘X  {SIZE({Y  I  Sji.lVame(X,y)})  >  vi 

V  SIZE{{Y  I  S'A.Name{X,Y)})  <  V2Y 

and  assuming  a'  is  not  of  the  form  generated  by  Equations  7.70  or  7.73,  then  by  Equa¬ 
tion  7.74  there  exists  an  axiom  ax  in  €..Axiom  where  ax  is  the  logical  disjunction  of  the 
set  of  subaxioms  generated  for  each  Sj  in  a'  such  that 

Si  ='X  e  c.Name  ^  SIZE(IMAGE{A,X))  =  vY 
or 

Si  =“X  €  c.Name  =►  {SIZE{IMAGE{A,X))  >  vi 
V  SIZE{IMAGE{A,X))  <  V2T 

Thus  by  OMT-54  there  exists  a  c  €  C.Connection  such  that  c.Mult  =  Specified,  and 
there  exists  some  {vi,V2)  €  c.Spedfied  {v2  may  be  undefined)  for  each  Si  in  ax. 

Then  by  Equation  7.55  there  exists  an  a  in  S a- Axioms  such  that  for  each  spec-range  6 
c.Spedfied  there  exists  a  subaxiom  in  a  of  the  form 

“X  €  c.Name  =>  SIZE{{Y  \  SA.Name{X,Y)})  =  s.valuel” 
or 

“A"  e  c.Name  {SIZE{{Y  \  SA.Name{X,Y)})  >  s.valuel 
V  SIZE{{Y  I  SA.Name{X,Y)})  <  s.value2Y‘ 

Since  c.Name  =  s  and  SA-Name  —  S^-Name,  it  must  be  true  that  for  each  subaxiom 
in  a'  there  exists  an  equivalent  subaxiom  in  a,  and  thus  a  =  a'.  Therefore,  any  axiom 
in  S'a  generated  by  Equation  7.74  also  exists  in  Sa- 
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Therefore,  since  for  each  type  of  axiom  in  S'j^. Axioms,  there  is  an  equivalent  axiom 
in  SA-Axiom,  then  S'j^.Axioms  C  SA-Axioms,  and,  since  I  have  previously  shown  that 
S A- Axioms  C  S'j^. Axioms  it  is  clear  that  SA-Axioms  =  S'j^.Axioms 

Therefore,  since  each  specification  in  OM  is  in  OM',  each  specification  in  OM'  is  in  OM, 
and  each  component  within  each  specification  in  OM  is  in  the  associated  specification  in  OM'  and 
vice  versa,  it  is  obvious  that  OM  =  OM'.  □ 

F.2  Dynamic  Model  Correctness  Proof 

In  this  section.  Theorem  VIL2  is  proved. 

Proof.  Preservation  of  the  dynamic  model  semantics  by  r  is  established  by  showing  the 
equivalence  of  two  sets  of  dynamic  model  semantics,  M  and  M',  created  from  a  generic  OMT 
domain  theory,  Q.  M  is  the  dynamic  model  semantics  defined  by  transforming  Q  hy  (p  while  M' 
is  the  dynamic  model  semantics  defined  by  transforming  G  by  t,  into  an  0-Slang  domain  theory 
O,  and  then  by  w.  In  this  proof,  I  assume  that  Q  has  a  well  defined  dynamic  model  in  which  C  is 
a  class. 

I  prove  the  theorem  by  showing  that,  given  a  valid  generic  OMT  domain  theory  Q,  each 
component  defined  in  M  {Q,  E,  A  and  6)  exist  in  M'  and  that  each  component  defined  in  M'  exists 
in  M. 

1.  Q^Q'. 

To  show  that  Q  =  Q',1  first  show  that  Q  Q  Q'  and  then  that  Q'  C  Q.  By  assumption,  C  is 
some  class  in  Q  with  a  well-defined  dynamic  model.  Therefore,  for  each  state  s  in  C.State,  by 
</?,  s.Name  is  in  Q. 
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If  s  in  estate,  then  by  rule  OMT-68  {s.Name,  ,x)  is  in  CState  (with  the  exception  of  Initial- 
State-Marker  by  function  tTj  as  defined  in  Equation  7.19)  and  by  u,  s.Name  is  in  Q'.  The 
definition  of  Q'  in  uj  also  explicitly  re-inserts  the  Initial-State- Marker,  therefore,  Q  C  Q'. 

By  u,  if  s.Name  is  in  Q'  then  s.Name  must  be  the  name  of  some  state  s  in  C.State  or  the 
Initial-State-Marker.  Rules  OMT-68  and  OMT-72  are  the  only  translation  rules  in  r  that 
create  elements  of  C.State.  However,  since  OMT-72  translates  substates  of  some  state  s  in 
the  states  of  C  and,  by  assumption  the  dynamic  model  has  been  translated  into  a  simple  finite 
state  machine  automata  as  defined  in  Section  5.4.4  without  substates,  if  s  is  in  C.State  it  had 
to  be  placed  there  by  OMT-68,  and  thus  s.Name  is  the  name  of  some  state  in  C.State.  Since 
the  Initial-State-Marker  is  present  in  C.State,  it  is  in  Q  as  well.  Thus  Q'  C  Q  and  therefore 
Q  =  Q'. 

2.  S  =  E'. 

To  show  that  E  =  S',  I  first  show  that  E  C  E'  and  then  that  S'  C  S.  By  definition  of  E  in 
if,  for  t.Name  to  be  in  the  set  E,  the  corresponding  transition,  t,  must  exist  in  C.Transition. 
Then,  if  t  €  C.Transition,  by  OMT-74,  an  event  {t.Name,  x,y)  is  in  C.Event  that  is  mapped 
by  w  to  S'.  Thus  E  C  S'. 

Assume  t.Name  is  in  S'.  Then  by  definition  of  S'  in  w,  there  must  be  some  {t.Name,  x' ,y') 
in  C.Event.  And,  since  Rule  OMT-74  is  the  only  rule  in  t  that  translates  components  in  Q  to 
C.Event  (OMT-17  only  creates  events  in  C.Event  when  there  is  no  dynamic  model  defined 
by  the  user),  t.Name  must  be  the  name  of  some  transition  t  £  C.Transition,  which  by  (f 
implies  t.Name  £  S.  Therefore  E'  C  E  and  knowing  that  S  =  S'  from  above,  implies  S'  =  S. 

3.  A  =  A' 

To  show  that  A  =  A',  I  first  show  that  A  C  A'  and  then  that  A'  C  A.  Assume  t  is  some 
transition  in  C.Transition,  then  by  definition  of  A  in  ip,  for  each  a  in  t. Action,  msig(a),  as 
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defined  in  Equation  7.77,  is  in  A  if  and  only  if  a.Name  ^  SEND  and  msig{a.Action)  is  in 
A  if  and  only  if  a.Name  =  SEND. 


Assume  a.Name  ^  SEND  and  thus  msig{a)  =  {a.Name,  [C.Name]  ||  dcmain{a.Parameter), 
[C.Name])  is  in  A  by  definition  of  tp.  By  Rule  OMT-75,  m  =  {a.Name,  [C.Name]  |1 
domain{a.Parameter),  [C.Name]  )  €  C.Method,  by  Rule  OMT-74  {t.Name,  [C.Name]  || 
domain{t.Parameter),  [C.Name])  G  C.Event,  and  by  OMT-82  an  axiom  of  the  form 

^^oldstate{t.FromState)  A  guard  newstate{t) 

A  ...  ATTR-EQUAL{t.Name{  ...  ),a.Name{  ...  ))  ...” 


is  in  C.Axiom.  Therefore,  by  definition  of  A'  in  cj,  m  G  A',  and  msig{a)  e  A  =  {a.Name, 
[C.Name]\\domain{a. Parameter),  [C.Name)  =  m  G  A'. 

If  a.Name  =  SEND,  by  definition  oicp,  esig{a. Action)  =  {a.  Action. Name,  [a.  Action. Name- 
SORT]  II  domain{a.Action.Parameter),  [a.Action.Name-SORT]  )  6  A.  By  Rule  OMT-76 
and  OMT-77,  and  event  theory  Qe  is  created  and  Cs.Name  =  a.Action.N ame,  by  Rule  OMT- 
79  e  =  {a.Action.N ame,  [a.Action.N ame]  ||  domain{a. Action),  [a.Action.Name-SORT]) 
G  Ce. Event,  and  by  Rule  OMT-80  a.Action.N ame  G  ^.Import.  Then  by  definition  of 
A'  in  cu,  e  €  A'  and  esig{a. Action)  G  N  —  {a.Action.N ame,  [a.Action.Name-SORT]  || 
domain{a. Action. Parameter),  [a.Action.Name-SORT])  =  e  G  A'.  Therefore,  A  C  A'. 

An  event  theory  can  only  be  created  by  Rules  OMT-76  through  OMT-79,  or  Rule  OMT-40; 
however,  since  the  event  theories  defined  in  Rule  OMT-40  are  broadcast  theories  and  are  only 
referenced  in  aggregate  specifications,  an  event  theory  whose  name,  CE.Name  is  found  in 
the  import  block  of  some  class  specification  C  (as  required  by  the  definition  of  A'  in  u>), 
must  have  been  created  by  Rules  OMT-76  through  OMT-79.  So,  if  there  exists  an  event 
theory  Qe  such  that  Cffi.A’ame  =  n  and  n  G  C.Import  of  some  class  specification  C,  then  it 
must  be  the  case  that  there  exists  some  t  G  C.Transistion  with  an  action  a  G  t.Action  such 
that  a.Name  =  SEND,  a.Action.N ame  =  n,  and  esig{a)  =  e  G  CE-Event  (i.e.,  e  is  the 
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event  generated  by  a  via  Rule  OMT-79).  Therefore,  by  definition  of  ip,  esig{a)  e  A,  and  by 
defintion  of  cj,  e  €  A'. 

Assume  that  there  exists  some  m  6  A'  such  that  m  6  C.Method,  e  E  C.Event,  and  an  axiom 
a  E  C-Axiom  of  the  form 

C.Name-STATE(x)  =  q  ...  =>• 

C.Name-ST ATE{event{...))  =  q2  —  ATTR-EQUAL{e.NaTne{...),m.Name{...))  ... 

Since,  (1)  as  defined  in  Section  6.2.7  a  user  may  not  modify  a  state  attribute  except  through 
definition  of  a  transition  in  the  class  dynamic  model  and  (2)  the  assumption  for  this  proof 
that  a  dynamic  model  for  class  C  has  been  defined,  an  axiom  of  the  form  of  a, 

“C.Name-ST ATE{x)  =  q...  =>■  C.Name-STATE{event{...))  —  q^  ...” 

must  have  been  generated  by  Rule  OMT-82.  Therefore,  by  definition  of  the  method-invocation 
function  that  implements  Rule  OMT-82,  it  must  also  be  true  that  an  axiom  of  the  form  of  a 
with  the  substring 

“ATTR-EQUAL{e{...),  m(...))” 

must  have  been  generated  from  a  transition  t  E  C. Transition  such  that  e  =  t.Name  and  m  = 
a.Name  for  some  a  E  t.Action  where  a.Name  7^  SEND.  This  same  t  and  a  also  generated 
m  =  (a.iVame,  [C.A'ome]  ||  domain{a.ParameteT),[C.Name])  E  C.Method  by  OMT-75  and 
msig{a)  =  {a.Name,  [C.Name]\\domain{a.Parameter),[C. Name])  G  A  by  definition  of  95. 
Thus  A'  C  A  and,  already  knowing  that  A  C  A',  implies  A  =  A'. 

4.  S  =  S' 

To  show  that  5  =  (J',  I  show  that  if  I  pick  an  object  in  any  class  C  with  a  well-defined  dynamic 
model  such  that  the  object  is  in  some  arbitrary  state  q  E  Q  and  receive  input  event  a  E  E, 
S{q,a)  =  6'{q,a). 
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First,  pick  some  object  in  C  in  state  q  £  Q.  Upon  receipt  of  an  input  event  cr  €  S,  if 
there  exists  a  transition  t  £  C.Transition  such  that  t.FromState  =  q,  t.Name  =  a,  and 
t.Axiom  evaluates  to  true,  then  by  (p,  S{q,a)  =  t.ToState.  Otherwise,  if  there  is  no  transition 
t  £  C.Transition  such  that  t.FromState  =  q,  t.Name  =  a,  and  t.Axiom  evaluates  to  true, 
then  by  </3,  6{q,  o)  =  q. 

By  Rule  OMT-82,  for  all  t  £  C.Transition,  t  generates  an  axiom  in  C.Axiom  of  the  form 

C.Name-STATE{x)  =  q  A  guard  =>•  C.Name-STATE{a{...))  =  q2  ...  (F-1) 

where  q  =  t.FromState,  the  guard  is  simply  t.Axiom,  and  the  q2  =  t.ToState.  And,  as  shown 
above  in  Item  3,  no  other  axioms  of  this  form  can  be  entered  into  C.Axiom  using  any  other 
transformation  rules. 

Then,  knowing  that  Q  =  Q'  and  E  =  S'  from  Items  1  and  2  above,  I  choose  some  object 
in  class  C  in  state  q  £  Q.  Upon  receipt  of  an  input  event  cr  6  E,  if  there  exists  an  axiom 
in  C.Axiom  of  the  form  shown  in  Equation  F.l,  such  that  the  guard  {t.Axiom)  evaluates  to 
true  then  by  w,  S'{q,  a)  =  q2  =  t.ToState.  Otherwise,  if  there  is  no  axiom  of  the  appropriate 
form  such  that  the  guard  (t.Axiom)  evaluates  to  true  then  by  w,  6'{q,a)  =  q. 

Therefore,  since  for  all  possible  inputs,  {q,o),  S{q,cr)  =  6'{q,a),  it  must  be  the  case  that 
8  =  8'. 

5.  A  =  A' 

To  show  that  A  =  A',  I  show  that,  for  any  class  C  with  a  well-defined  dynamic  model,  if 
I  pick  an  object  in  the  class  in  any  arbitrary  state  q  £  Q  and  receive  input  event  cr  €  E, 
Xiq,cr)  =  X'{q,a). 

First,  choose  some  object  in  class  C  with  state  q  £  Q.  Upon  receipt  of  an  input  event  cr  G  E, 
if  there  exists  a  transition  t  £  C.Transition  such  that  t.FromState  =  q  and  t.Name  =  a. 
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and  t. Axiom  evaluates  to  true  then  by  (p,  X{q,  a)  =  sig{t. Action)  which  is  the  set  of  all  ac¬ 
tion/event  signatures  invoked/sent  in  response  to  the  transition  as  defined  in  Equation  7.79. 
Otherwise,  if  there  is  no  transition  t  e  C.Transition  such  that  t.FromState  =  q  and 
t.Name  =  a,  and  t. Axiom  evaluates  to  true  then  by  (p,  \{q,c)  =  {}. 

By  Rule  OMT-82,  for  all  t  €  C.Transition,  t  generates  an  axiom  in  ax  £  C. Axiom  of  the 
form  given  in  Equation  F.l  where  q  =  t.FromState,  the  guard  is  t. Axiom,  and  the  q2  = 
t.ToState.  The  method-invocations  function  translates  each  non-send  actions  a  £  t. Action  to 
a  subsequence  of  the  form 

ATTR-EQUAL(t.Name(  ...  ),a.Name{  ...  ))  ... 

and  the  function  event-sends  translates  each  send  event  e  £  t. Action  to  a  subsequence  of  ax 
of  the  form 

e.  Action. Name-OB  J{t.Name{...))  =  e.Action.Name{e.Action.Name-OBJ{x)...) 

As  discussed  above  in  Item  3,  only  Rule  OMT-82  is  capable  of  placing  axioms  of  this  form 
into  C.Axiom. 

Since  Q  —  Q'  and  E  =  S'  from  Items  1  and  2  above,  I  may  choose  some  object  in  class  C  in 
state  q  €  Q.  Upon  receipt  of  an  input  event  ct  £  S,  if  there  exists  an  axiom,  ax,  in  C.Axiom 
of  the  form  shown  in  Equation  F.l,  such  that  the  guard  {t. Axiom)  evaluates  to  true  then  by 
w,  A'(g,  cr)  =  action- set{ax).  By  Rule  OMT-82  all  actions  in  t  are  translated  into  either  a 
method  invocation  or  an  event  send  subsequence  in  ax.  The  function  action-set  as  defined 
in  Equation  7.80  returns  the  set  of  all  method  and  event  signatures  for  each  method/event 
subsequence  found  in  ax;  therefore,  action-set{ax)  =  sig{t. Action).  If,  on  the  other  hand, 
there  are  no  axioms  in  C.Axiom  of  the  form  shown  in  Equation  F.l,  such  that  the  guard 
{t. Axiom)  evaluates  to  true  then  by  u>,  A'(g,cr)  =  {}.  Therefore,  since  for  all  possible  inputs, 
{q,cr),  X{q,o)  =  X'{q,(j),  it  must  be  true  that  A  =  A'. 
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6.  qo  =  q'o 


The  initial  state  is  explicitly  represented  in  each  Q  dynamic  model  with  a  unique  identifier 
Initial-State-Marker,  however,  by  Rule  OMT-83,  a  transition,  t,  from  the  initial  state  (by  a 
new  event)  results  in  an  axiom  of  the  form 

C.Name-STATE(new-C.Name{...)  =  t.ToStateA 
method-invocations(t)  A  event-sends{t) 

Therefore,  there  is  no  explicit  representation  of  qo.  However,  Q,  S',  A',  and  q'g  explicitly 
incorporate  the  Initial-State-Marker  into  uj  and  thus  qo  —  qo- 

Therefore,  since  Q  =  Q',  S  =  E',  A  —  A',  6  =  S',  X  —  X'  and  50  =  q'o  it  can  be  concluded 
that  M  =  M'.  □ 

F.S  Functional  Model  Correctness  Proof 

In  this  section.  Theorem  VII.3  is  proved. 

Proof.  Preservation  of  the  functional  model  semantics  by  r  is  established  by  showing  the 
equivalence  of  two  sets  of  functional  model  semantics,  D  and  D' ,  created  from  a  generic  OMT 
domain  theory,  Q.  D  is  the  functional  model  semantics  defined  by  transforming  Q  hy  ip  while  D'  is 
the  functional  model  semantics  defined  by  transforming  Q  by  r,  into  an  0-Slang  domain  theory 
O,  and  then  by  u).  In  this  proof,  I  assume  that  Q  has  a  well  defined  functional  model  in  which  C  is 
a  class. 

I  prove  the  theorem  by  showing  that,  given  a  valid  generic  OMT  domain  theory  Q,  each 
component  defined  in  D  (C,  F,  K,  and  R)  exist  in  D'  and  that  each  component  defined  in  D' 
exists  in  D. 

1.  C  =  C'. 

I  show  (7  =  C"  by  showing  that  C  CC'  and  then  showing  C  C  C'. 


F-39 


*  CCC. 


For  any  c  G  C,  by  the  definition  of  C,  the  name  of  c  must  be  the  name  of  a  process  of  C, 
a  datastore  of  C,  or  the  symbol  Extern.  If  c  refers  to  a  process  in  C  then  by  Rule  OMT- 
85  or  Rule  OMT-86  the  process  referred  to  by  c  is  mapped  to  either  a  method  or  an 
operation  in  C  and  therefore,  by  definition  of  C ,  c  £  C . 

If  c  is  the  name  of  a  datastore  then  by  definition  of  a  valid  dataflow  diagram,  there 
must  be  a  dataflow  in  C.DataFlow  such  that  it  is  either  the  target  or  source.  Also, 
by  Assumptions  V.12  and  V.13  there  exists  a  process,  p,  such  that  p  only  accesses  or 
modifies  datastore  c.  Therefore,  by  Rule  OMT-87  there  must  be  an  axiom  in  C.Axiom 
such  that  the  following  is  a  substring. 

“...  op(datastore(X)  ...)  ...” 

This  substring  is  extracted  by  function  datastores  as  defined  in  Equation  7.83  and  thus, 
by  definition  of  C',  c  G  C'. 

If  c  is  Extern  then  by  definition  of  C",  c  G  C".  Therefore  C  CC. 

•  C  CC. 

Now,  assume  c  £  C.  If  c  G  C"  then  by  the  definition  of  C",  c  G  C.Method,  c  £ 
C.Operation,  c  £  datastores{C),  oi  c  —  Extern.  Since,  by  assumption,  all  methods  in 
C  are  defined  from  processes  in  C  via  Rule  OMT-85  there  must  be  a  process  in  C  whose 
name  is  c  and,  by  definition  of  C,  c  G  C. 

If  c  is  the  name  of  an  operation  in  C  then  by  the  assumption  that  adl  methods  in  C  are 
defined  from  processes  in  C  via  Rule  OMT-86  there  must  be  a  process  in  C  whose  name 
is  c  and  thus,  by  definition  of  (7,  c  G  C. 

If  c  is  a  datastore,  then  c  G  datastores{ax)  for  some  ax  £  C.Axiom  that  contains  the 
following  substring. 

“...  op(c(A)  ...)  ...” 
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Since  axioms  of  this  form  are  only  generated  by  Rule  OMT-87,  then  c  must  have  been 
in  datastore{C)  that,  by  definition  of  C,  implies  c  £  C. 

If  c  is  Extern  then  by  definition  of  C,  c  £  C  and  C  C  C.  Therefore  since  C  C  C  and 
CCC',C  =  C. 

2.  F  =  F'. 

I  show  that  F  =  F'  hy  showing  that  for  any  C  in  Q,  for  each  /  in  C.Dataflow,  f  £  F  and 
f  £  F'  and  nothing  else  is  in  F  or  F'. 

If  /  e  C.Dataflow,  then  trivially,  by  the  definition  of  F,  f  £  F  and  nothing  else  can  be  in  F. 

If  /  G  C.Dataflow,  it  is  a  datafiow  in  a  functional  model.  Given  a  valid  dataflow  diagram, 
as  shown  in  Table  7.1,  these  dataflows  can  be  (a)  an  input  to  a  process  (lines  1,  2,  10,  and 
14),  (b)  an  output  to  a  datastore  (line  11),  or  (c)  an  output  from  a  process  to  Extern  (lines 
8  and  12).  I  discuss  each  of  these  possibilities  below. 

(a)  There  are  two  unique  cases  to  consider  when  a  dataflow  is  an  input  to  a  process.  The 
input  may  be  to  a  top-level  process  (line  1  in  Table  7.1)  or  a  subprocess(lines  2,  10,  and 
14  in  Table  7.1).  Each  of  these  is  discussed  below. 

If  /  =  {f.Name,  f .Type,  f. Target,  f. Source)  is  an  input  to  a  process,  p,  where  p.Name 
=  f. Target  and  {f.Name,  f.Type)  =£  p.InFlows,  then  by  Rule  OMT-85  or  Rule  OMT- 
86  there  is  an  operation  or  method  defined  in  C  as  shown  below. 

{f. Target,  [...f.Type...],  [...])  G  {C.Method  U  C.Operation) 

Thus  by  Rule  OMT-87  there  exists  an  axiom,  ax,  in  C.Axiom  of  the  form 
ax  =“m(ii...im)  —  oi...o„...  A  ri...ro  =  sp{di...dp)...'" 
such  that  m  =  f .Target,  or,  sp  =  f. Target. 

i.  If  m  =  f. Target,  then  some  parameter  ii...im  =  f.Name  such  that  the  variables  in 
the  function  dataflows-of(ax)  take  on  the  following  values. 
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Extern  =  f.  Source 
t.Name  =  f. Target 
P3  =  f.Name 
itype{p3,  t)  =  f.Type 


Thus  by  the  defintions  of  dataflows-of  &nd  F',  {ps,  itype(j)3,t),  Extern,  t.Name)  = 
{f.Name,  f.Type,  f. Source,  f. Target)  e  F' 

ii.  If  sp  =  f. Target,  then  some  parameter  in  di...dm  =  f.Name  such  that  the  variables 
in  the  function  dataflows- of  (ax)  take  on  the  following  values. 


opi.Name 
opi  .Name 
Pi 

itype{pi,opi) 


(.Source 

(.Target 

f.Name 

f.Type 


Therefore,  by  the  defintions  of  dataflows-of  and  F',  (pi,  itype{pi,opi),  op2.Name, 
opi.Name)  =  {(.Name,  f.Type,  (.Source,  (.Target)  £  F' 

(b)  If  /  =  (f  .Name,  f  .Type,  f  .Target,  (.Source)  is  an  output  to  a  datastore,  d,  then  by 
Assumptions  V.12  and  V.13  there  exists  a  process  p  such  that  /  is  the  only  datastore 
output  of  p.  Therefore,  p  is  a  method  such  that  p.Name  =  (.Source  and  by  Rule  OMT- 
85  there  is  a  method  defined  in  C  as  shown  below. 

{(.Source,  [f.TaTget...],[f. Target])  G  C.Method 
Thus  by  Rule  OMT-87  there  exists  an  axiom,  ax,  in  C.Axiom  of  the  form 

ax  =“m(ii...i,n)  =  oi...o„...  A ri...r„  =  sp{di...dp)...’' 

such  that  (.Source  =  sp  and  ri...r„  =  ri  =  (.Target  and  the  variables  in  the  function 
dataflows-of( ax)  take  on  the  following  values. 
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opi.Name  =  f. Source 
o  =  f. Target 
dsnaTne{o)  =  f.Name 
dstype{o)  —  f.Type 

Therefore,  by  the  defintions  of  dataflows-of  and  F',  {dsname{o),  dstype{o),  opi.Name, 
o)  =  {f.Name,  f.Type,  f. Source,  f. Target)  £  F' 

(c)  There  are  two  unique  cases  to  consider  when  an  output  goes  to  Extern.  The  output 
may  come  from  a  subprocess,  or  it  may  come  from  a  top-level  object.  Each  of  these  is 
discussed  separately. 

i.  If  /  =  {f.Name,  f.Type,  f. Target,  f. Source)  is  an  output  from  a  subprocess  p,  with 
p.Name  =  f. Source,  to  an  external  object  such  that  f .Target  =  Extern,  then  p 
must  be  an  operation  since  the  only  output  from  a  method  is  the  class  sort  which 
is  implied  and  not  actually  part  of  the  dataflow  diagram.  Thus  by  Rule  OMT-86 
there  is  an  operation  defined  in  C  as  shown  below. 

{/.Source,  [...],  [...f.Type...])  6  C.Operation 
Thus  by  Rule  OMT-87  there  exists  an  axiom,  ax,  in  C.Axiom  of  the  form 
ax  =“m{ii...im)  =  oi...o„...  A  ri...ro  =  sp{di...dp)...” 
such  that  sp  =  f .Source  and  some  output  of  sp,  r\...rm  =  f.Name  and  the  variables 
in  the  function  dataflows-of(ax)  take  on  the  following  values. 

Extern  =  f. Target 
opi.Name  =  f. Source 
o  =  f.name 
otype{o,opi)  =  f.Type 

Then  by  the  defintions  of  dataflows-of  and  F',  {o,  otype{o,sp),  opi.Name,  Extern) 
=  {f.Name,  f.Type,  f. Source,  f .Target)  £  F' 
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ii.  If  /  =  {f.Name,  f.Type,  /.Target,  /.Source)  is  an  output  from  a  top-level  process 
p,  where  p.Name  =  /.Source,  then  p  must  be  an  operation  since  the  only  output 
from  a  method  is  the  class  sort  which  is  implied  and  not  actually  part  of  the  dataflow 
diagram.  Thus  by  Rule  OMT-86  there  is  an  operation  deflned  in  C  as  shown  below. 

{/.Source,  [...],  [.../.Type...])  €  C.Operation 
Thus  by  Rule  OMT-87  there  exists  an  axiom,  ax,  in  C.Axiom  of  the  form 
ax  =“m(ii...im)  =  oi...On...  Ari...ro  =  3p{di...dp)..." 
such  that  m  =  /.Source  and  some  output  of  m,  oi...Om  —  /.Name  and  the  variables 
in  the  function  data/iows-o/(ax)  take  on  the  following  values. 

Extern  =  /.Target 
t.Name  =  /.Source 
P3  =  /.name 
otype(p3,  t)  =  /.Type 

Thus  by  the  deflations  of  data/lows-o/ and  F',  (ps,  otype{pz,t),  t.Name,  Extern)  = 
{/.Name,  /.Type,  /.Source,  /.Target)  £  F' 

Therefore,  since  if  /  €  C.Data/low  is  either  (a)  an  input  to  a  process,  (b)  an  output  to  a 
datastore,  or  (c)  an  output  from  the  top-level  process  of  a  dataflow  diagram,  then  /  €  F'. 
Also,  given  the  initial  assumption  that  all  processes  p'mC  are  processes  in  a  functional  model 
deflned  in  C,  all  axioms  produced  by  OMT-87  use  only  processes  from  a  functional  model  of  C. 
Since  OMT-87  is  the  only  rule  capable  of  producing  axioms  in  <C.Axiom  of  the  form  required 
by  the  function  data/lows-o/,  all  sources  and  targets  extracted  from  some  axiom  in  C.Axicmi 
must  be  processes  in  a  functional  model  of  C.  Finally,  given  the  uniqueness  of  dataflow  names 
by  Assumption  V.19,  the  fact  that  there  must  be  in  inflow  and  an  outflow  for  each  input  and 
output  of  a  process  in  a  valid  dataflow  diagram  (by  Assumption  V.18),  and  the  definition  of 
OMT-87,  it  is  clear  that  there  are  no  dataflows  in  F'  not  derived  from  a  dataflows  in  a  C 
functional  model. 
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3.  K  =  K'. 


Since  I  showed  in  Item  1  that  C  —  C  and  by  definition  their  definitions,  each  includes  the 
symbol  Extern,  it  is  obvious  that  C  \  {Extern}  =  C  \  {Extern}  and  thus  K  =  K'. 

4.  J?  =  R'. 

Since  the  definition  of  R  uses  the  set  dfmerge{C.DataFlow),  which  is  the  definition  F,  its 
definition  is  equivalent  to  Equation  F.2. 

{{x,y)  I  {x,y  ^  F  A  x.Target  =  y. Source  A  x.Target  ^  Extern) 

y  {{x,z)&RA{z,y)eR)}  (F.2) 

And,  since  the  defintion  of  R'  uses  the  set  dfmerge{{f  \  a  £  C-Axiom  A  /  £  dataflows- 
of{a)},  which  is  the  definition  of  F',  its  definition  is  equivalent  to  Equation  F.3. 

I  {x,yeF') 

A  x.Target  =  y. Source  A  x.Target  Extern) 
\/i{x,z)€R'A{z,y)&R')}  (F.3) 

And  finally,  since  F  =  F',  Equations  F.2  and  F.3  are  equivalent  and  thus  R  =  R'. 

Since,  as  shown  above,  C  =  C ,  F  =  F',  K  =  K,  and  R  =  R' ,  then  D  =  D'  and  therefore, 
the  translation  r  preserves  the  semantics  of  the  generic  OMT  functional  model.  □ 

F.4  Summary 

This  appendix  presents  the  proofs  of  Theorems  VII.l,  VII.2,  and  VII.3.  These  theorems  show 
that  the  transformation  rules  as  defined  in  Chapter  VII  preserve  the  semantics  of  the  the  object 
model,  the  dynamic  model,  and  the  functional  model  as  defined  Chapter  V. 
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Appendix  G.  Feasibility  Demonstration  0-Slang  Output 


G.l  Pump  0-Slang 

class  CLUTCH  is 
class-sort  CLUTCH 
import  START-FUEL 
sort  CLUTCH-STATE 

attributes  START-FUEL-OB J ;  CLUTCH  ->  START-FUEL-SORT 
state-attributes  CLUTCH-STATE:  CLUTCH  ->  CLUTCH-STATE 
methods  CREATE-CLUTCH :  ->  CLUTCH 
states 

CLUTCH-DISABLED:  ->  CLUTCH-STATE 
CLUTCH-FREE:  ->  CLUTCH-STATE 
CLUTCH-ENGAGED:  ->  CLUTCH-STATE 
events 

FREE-CLUTCH:  CLUTCH  ->  CLUTCH 
DISABLE-CLUTCH:  CLUTCH  ->  CLUTCH 
ENGAGE-CLUTCH:  CLUTCH  ->  CLUTCH 
NEW-CLUTCH:  ->  CLUTCH 
axioms 

CLUTCH-DISABLED  <>  CLUTCH-FREE; 

CLUTCH-DISABLED  <>  CLUTCH-ENGAGED; 

CLUTCH-FREE  <>  CLUTCH-ENGAGED; 

ATTR-EQUAL(C1,  C2)  <=>  (START-FUEL-QBJ(Cl)  =  START-FUEL-0BJ(C2) ) ; 
(CLUTCH-STATE(NEW-CLUTCH(C))  =  CLUTCH-DISABLED 

k  ATTR-EQUAL(NEW-CLUTCH(C),  CREATE-CLUTCH(C))) ; 

(CLUTCH-STATE(C)  =  CLUTCH-FREE)  =>(CLUTCH-STATE(ENGAGE-CLUTCH(C))  =  CLUTCH-ENGAGED 
k  START-FUEL-OBJ(ENGAGE-CLUTCH<C))  =  START-FUEL(START-FUEL-OBJ(C))) ; 
(CLUTCH-STATE(C)  =  CLUTCH-FREE)  =>(CLUTCH-STATE(DISABLE-CLUTCH(C) )  =  CLUTCH-DISABLED); 
(CLUTCH-STATE(C)  =  CLUTCH-FREE)  =>(CLUTCH-STATE(FREE-CLUTCH(C) )  =  CLUTCH-ENGAGED); 
(CLUTCH-STATE(C)  =  CLUTCH-DISABLED)  =>(CLUTCH-STATE(FREE-CLUTCH(C) )  =  CLUTCH-FREE); 
CLUTCH-STATE (C)  =  CLUTCH-DISABLED  =>  CLUTCH-STATE(ENGAGE-CLUTCH(C) )  =  CLUTCH-DISABLED; 
CLUTCH-STATE (C)  =  CLUTCH-DISABLED  =>  CLUTCH-STATE(DISABLE-CLUTCH(C) )  =  CLUTCH-DISABLED; 
CLUTCH-STATE (C)  =  CLUTCH-DISABLED  =>  CLUTCH-STATE(FREE-CLUTCH(C) )  =  CLUTCH-DISABLED; 
CLUTCH-STATE (C)  =  CLUTCH-FREE  =>  CLUTCH-STATE(FREE-CLUTCH(C) )  =  CLUTCH-FREE; 
CLUTCH-STATE (C)  =  CLUTCH-ENGAGED  =>  CLUTCH-STATE(ENGAGE-CLUTCH(C) )  =  CLUTCH-ENGAGED; 
CLUTCH-STATE (C)  =  CLUTCH-ENGAGED  =>  CLUTCH-STATE(DISABLE-CLUTCH(C) )  =  CLUTCH-ENGAGED; 
CLUTCH-STATE(C)  =  CLUTCH-ENGAGED  =>  CLUTCH-STATE(FREE-CLUTCH(C) )  =  CLUTCH-ENGAGED; 
CLUTCH-STATE(C)  =  CLUTCH-ENGAGED  =>  CLUTCH-STATE(FREE-CLUTCH(C) )  =  CLUTCH-ENGAGED 
end-class 


class  CLUTCH-CLASS  is 
class-sort  CLUTCH-CLASS 
contained-class  CLUTCH 
events 

FREE-CLUTCH:  CLUTCH-CLASS  ->  CLUTCH-CLASS 
DISABLE-CLUTCH:  CLUTCH-CLASS  ->  CLUTCH-CLASS 
ENGAGE-CLUTCH:  CLUTCH-CLASS  ->  CLUTCH-CLASS 
NEW-CLUTCH-CLASS:  ->  CLUTCH-CLASS 
eixioms 

NEW-CLUTCH-CLASS  0  =  EMPTY-SET; 

fa  (C:CLUTCH.  CC: CLUTCH-CLASS)  in(C,  CC)  <=>  in(ENGAGE-CLUTCH(C) .  ENGAGE-CLUTCH (CC) ) ; 

fa  (C:CLUTCH,  CC: CLUTCH-CLASS)  in(C,  CC)  <=>  in(DISABLE-CLUTCH(C) ,  DISABLE-CLUTCH(CC)) ; 

fa  (C:CLUTCH,  CC: CLUTCH-CLASS)  in(C,  CC)  <=>  in(FREE-CLUTCH(C) ,  FREE-CLUTCH (CC) ) ; 
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fa  (CrCLUTCH,  CC: CLUTCH-CLASS)  in(C,  CC)  <=>  in(FREE-CLUTCH(C) ,  FREE-CLUTCH(CC) ) 
end-class 


class  HOLSTER  is 
class-sort  HOLSTER 
sort  HOLSTER-STATE 

state-attributes  HOLSTER-STATE:  HOLSTER  ->  HOLSTER-STATE 

methods  CREATE-HOLSTER :  ->  HOLSTER 

states 

HOLSTER-WAIT:  ->  HOLSTER-STATE 

HOLSTER-WORKING:  ->  HOLSTER-STATE 
events 

CLOSE-HOLSTER-SWITCH:  HOLSTER  ->  HOLSTER 

RELEASE-HOLSTER-SWITCH:  HOLSTER  ->  HOLSTER 

NEW-HOLSTER:  ->  HOLSTER 
axioms 

HOLSTER-WAIT  <>  HOLSTER-WORKING; 

(HOLSTER-STATE (NEW-HOLSTER(H))  =  HOLSTER-WAIT 

&  ATTR-EQUAL(NEW-HOLSTER(H) ,  CREATE-HOLSTER (H) ) ) ; 

(HOLSTER-STATE (H)  =  HOLSTER-WAIT) 

=>  (HOLSTER-STATE(RELEASE-HOLSTER-SWITCH(H))  =  HOLSTER-WORKING); 

(HOLSTER-STATE (H)  =  HOLSTER-WORKING) 

=>  (HOLSTER-STATE(CLOSE-HOLSTER-SWITCH(H))  =  HOLSTER-WAIT); 

HOLSTER-STATE (H)  =  HOLSTER-WAIT 

=>  HOLSTER-STATE(CLOSE-HOLSTER-SWITCH(H))  =  HOLSTER-WAIT; 

HOLSTER-STATE (H)  =  HOLSTER-WORKING 

=>  HOLSTER-STATE (RELEASE-HOLSTER-SWITCH (H))  =  HOLSTER-WORKING 
end-class 


class  HOLSTER-CLASS  is 
class-sort  HOLSTER-CLASS 
contained-class  HOLSTER 
events 

CLOSE-HOLSTER-SWITCH:  HOLSTER-CLASS  ->  HOLSTER-CLASS 
RELEASE-HOLSTER-SWITCH:  HOLSTER-CLASS  ->  HOLSTER-CLASS 
NEW-HOLSTER-CLASS:  ->  HOLSTER-CLASS 
axioms 

NEW-HOLSTER-CLASS  0  =  EMPTY-SET; 

fa  ((H:  HOLSTER),  HC:  HOLSTER-CLASS)  in(H,  HC) 

<=>  in(RELEASE-HOLSTER-SWITCH(H) ,  RELEASE-HOLSTER-SWITCH (HC) ) ; 
fa  ((H:  HOLSTER),  HC:  HOLSTER-CLASS)  in(H,  HC) 

<=>  in(CLOSE-HOLSTER-SWITCH(H) ,  CLOSE-HOLSTER-SWITCH(HC)) 
end-class 


class  MOTOR  is 
class-sort  MOTOR 

import  FREE-CLUTCH,  DISABLE-CLUTCH 

sort  MOTOR-STATE 

attributes 

DISABLE-CLUTCH-OBJ:  MOTOR  ->  DISABLE-CLUTCH-SORT 
FREE-CLUTCH-OBJ:  MOTOR  ->  FREE-CLUTCH-SORT 
state-attributes 

MOTOR-STATE:  MOTOR  ->  MOTOR-STATE 
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methods 

CREATE-MOTOR:  ->  MOTOR 
states 

MOTOR-DISABLED:  ->  MOTOR-STATE 
MOTOR-RUNNING:  ->  MOTOR-STATE 
events 

STOP-MOTOR:  MOTOR  ->  MOTOR 
START-PUMP-MOTOR:  MOTOR  ->  MOTOR 
NEW-MOTOR:  ->  MOTOR 
axioms 

MOTOR-DISABLED  <>  MOTOR-RUNNING; 

ATTR-EQUAL(M1,  M2)  <=>  (DISABLE-CLUTCH-OBJ(Ml)  =  DISABLE-CLUTCH-0BJ(M2) 

&  FREE-CLUTCH-OBJ(Ml)  =  FREE-CLUTCH-0BJ(M2) ) ; 
(MOTOR-STATE (NEW-MOTOR (M))  =  MOTOR-DISABLED 

&  ATTR-EQUAL(NEW-MOTOR(M),  CREATE-MOTOR(M))) ; 

(MOTOR-STATE (M)  =  MOTOR-DISABLED) 

=>  (MOTOR-STATE(START-PUMP-MOTQR(M))  =  MOTOR-RUNNING 
&  FREE-CLUTCH-OBJ(START-PUMP-MOTOR(M) ) 

=  FREE-CLUTCH(FREE-CLUTCH-OBJ(M) ) ) ; 

(MOTOR-STATE (M)  =  MOTOR-RUNNING) 

=>  (MOTOR-STATE(STOP-MOTOR(M))  =  MOTOR-DISABLED 
&  DISABLE-CLUTCH-OB J (STOP-MOTOR(M) ) 

=  DISABLE-CLUTCH(DISABLE-CLUTCH-OBJ(M))) ; 
MOTOR-STATE (M)  =  MOTOR-DISABLED 

=>  MOTOR-STATE(STOP-MOTOR(M))  =  MOTOR-DISABLED; 

MOTOR-STATE (M)  =  MOTOR-RUNNING 

=>  MOTOR-STATE(START-PUMP-MOTOR(M))  =  MOTOR-RUNNING 
end-class 


class  MOTOR-CLASS  is 
class-sort  MOTOR-CLASS 
contained-class  MOTOR 
events 

STOP-MOTOR:  MOTOR-CLASS  ->  MOTOR-CLASS 
START-PUMP-MOTOR:  MOTOR-CLASS  ->  MOTOR-CLASS 
NEW-MOTOR-CLASS:  ->  MOTOR-CLASS 
axioms 

NEW-MOTOR-CLASS 0  =  EMPTY-SET; 

fa  (M: MOTOR,  MC: MOTOR-CLASS)  in(M,  MC) 

<=>  in(START-PUMP-MOTOR(M),  START-PUMP-MOTOR(MC) ) ; 
fa  (M:MOTOR,  MC: MOTOR-CLASS)  in(M,  MC)  <=>  in(STOP-MOTOR(M) ,  STOP-MOTOR(MC) ) 
end-class 


class  GUN  is 
class-sort  GUN 

import  START-TIMER,  DISABLE-PUMP,  CLOSE-HOLSTER-SWITCH, 

FREE-CLUTCH,  ENGAGE-CLUTCH,  RELEASE-HOLSTER-SWITCH 
sort  GUN-STATE 
attributes 

RELEASE-HOLSTER-SWITCH-OB  J : 

GUN  ->  RELEASE-HOLSTER-SWITCH-SORT 
ENGAGE-CLUTCH-OBJ:  GUN  ->  ENGAGE-CLUTCH-SORT 
FREE-CLUTCH-OBJ:  GUN  ->  FREE-CLUTCH-SORT 
CLOSE-HOLSTER-SWITCH-OBJ :  GUN  ->  CLOSE-HOLSTER-SWITCH-SORT 
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DISABLE-PUMP-OB J :  GUN  ->  DISABLE-PUMP-SORT 
START-TIMER-OB J :  GUN  ->  START-TIMER-SORT 
state-attributes 

GUN-STATE:  GUN  ->  GUN-STATE 
methods 

CREATE-GUN:  ->  GUN 
states 

GUN-DISABLED:  ->  GUN-STATE 
GUN-ENABLED:  ->  GUN-STATE 
GUN-QN:  ->  GUN-STATE 
events 

REMOVE-GUN:  GUN  ->  GUN 
RELEASE-TRIGGER:  GUN  ->  GUN 
DEPRESS-TRIGGER:  GUN  ->  GUN 
CUT-OFF-SUPPLY:  GUN  ->  GUN 
REPLACE-GUN:  GUN  ->  GUN 
NEW-GUN:  ->  GUN 
axioms 

GUN-DISABLED  <>  GUN-ENABLED: 

GUN-DISABLED  <>  GUN-ON; 

GUN-ENABLED  <>  GUN-ON; 

ATTR-EQUAL(G1.  G2)  <=>  (RELEASE-HOLSTER-SWITCH-OBJ(Gl)  =  RELEASE-H0LSTER-SWITCH-0BJ(G2) 
4  ENGAGE-CLUTCH-OBJ(Gl)  =  ENGAGE-CLUTCH-0BJ(G2) 

4  FREE-CLUTCH-OBJ(Gl)  =  FREE-CLUTCH-0BJ(G2) 

4  CLOSE-HOLSTER-SWITCH-OBJ(Gl)  =  CL0SE-H0LSTER-SWITCH-0BJ(G2) 

4  DISABLE-PUMP-QBJ(Gl)  =  DISABLE-PUMP-OB J(G2) 

4  START-TIMER-OBJ(Gl)  =  START-TIMER-0BJ(G2)) ; 
(GUN-STATE(NEW-GUN(G))  =  GUN-DISABLED  4  ATTR-EQUAL(NEW-GUN(G) ,  CREATE-GUN(G))) ; 

(GUN-STATE(G)  =  GUN-ENABLED)  =>  (GUN-STATE(REPLACE-GUN(G) )  =  GUN-DISABLED 

4  START-TIMER-OB J (REPLACE-GUN (G))  =  START-TIMER(START-TIMER-OBJ(G) ) 

4  DISABLE-PUMP-OBJ(REPLACE-GUN(G))  =  DISABLE-PUMP (DISABLE-PUMP-OB J(G)) 
4  CLOSE-HOLSTER-SWITCH-OBJ (REPLACE-GUN (G)  ) 

=  CLaSE-HOLSTER-SWITCH(CLOSE-HOLSTER-SWITCH-OBJ (G) ) ) ; 

(GUN-STATE(G)  =  GUN-ON)  =>  (GUN-STATE(CUT-OFF-SOPPLY(G) )  =  GUN-ENABLED 

4  FREE-CLUTCH-OBJ(CUT-OFF-SUPPLY(G))  =  FREE-CLUTCH(FREE-CLUTCH-OBJ(G))) ; 
(GUN-STATE(G)  =  GUN-ENABLED)  =>  (GUN-STATE(DEPRESS-TRIGGER(G) )  =  GUN-ON 
4  ENGAGE-CLUTCH-OB J (DEPRESS-TRIGGER(G) ) 

=  ENGAGE-CLOTCH(ENGAGE-CLUTCH-OBJ(G) ) ) ; 

(GUN-STATE(G)  =  GUN-ENABLED)  =>  (GUN-STATE(RELEASE-TRIGGER(G) )  =  GUN-ON 

4  FREE-CLUTCH-OBJ(RELEASE-TRIGGER(G))  =  FREE-CLUTCH(FREE-CLUTCH-OBJ(G) ) ) ; 
(GUN-STATE(G)  =  GUN-DISABLED)  =>  (GUN-STATE(REMOVE-GUN(G) )  =  GUN-ENABLED 
4  RELEASE-HOLSTER-SWITCH-OBJ(REHOVE-GUN(G) ) 

=  RELEASE-HOLSTER-SWITCH(RELEASE-HOLSTER-SWITCH-OBJ(G))) : 
GUN-STATE(G)  =  GUN-DISABLED  =>  GUN-STATE(REPLACE-GUN(G) )  =  GUN-DISABLED; 

GUN-STATE(G)  =  GUN-DISABLED  =>  GUN-STATE(CUT-OFF-SUPPLY(G))  =  GUN-DISABLED; 

GUN-STATE(G)  =  GUN-DISABLED  =>  GUN-STATE(DEPRESS-TRIGGER(G) )  =  GUN-DISABLED; 
GUN-STATE(G)  =  GUN-DISABLED  =>  GUN-STATE(RELEASE-TRIGGER(G) )  =  GUN-DISABLED; 
GUN-STATE(G)  =  GUN-ENABLED  =>  GUN-STATE(CDT-OFF-SUPPLY(G) )  =  GUN-ENABLED; 

GUN-STATE(G)  =  GUN-ENABLED  =>  GUN-STATE(REHOVE-GUN(G))  =  GUN-ENABLED; 

GUN-STATE(G)  =  GUN-ON  =>  GUN-STATE (REPLACE-GUN (G))  =  GUN-ON; 

GUN-STATE(G)  =  GUN-ON  =>  GUN-STATE(DEPRESS-TRIGGER(G) )  =  GUN-DN; 

GUN-STATE(G)  =  GUN-ON  =>  GUN-STATE(RELEASE-TRIGGER(G) )  =  GUN-ON; 

GUN-STATE(G)  =  GUN-ON  =>  GUN-STATE (REMOVE-GUN (G) )  =  GUN-ON 
end-class 
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class  GUN-CLASS  is 

class-sort  GUN-CLASS  contained-class  GUN 


events 


REMOVE-GUN:  GUN-CLASS  ->  GUN-CLASS 
RELEASE-TRIGGER:  GUN-CLASS  ->  GUN-CLASS 
DEPRESS-TRIGGER:  GUN-CLASS  ->  GUN-CLASS 
CUT-OFF-SUPPLY:  GUN-CLASS  ->  GUN-CLASS 
REPLACE-GUN:  GUN-CLASS  ->  GUN-CLASS 
NEW-GUN-CLASS:  ->  GUN-CLASS 


axioms 


NEW-GUN-CLASS 0  = 
fa  ((G:  GUN),  GC: 
fa  ((G:  GUN).  GC: 
fa  ((G:  GUN),  GC: 
fa  (CG:  GUN),  GC: 
fa  ((G:  GUN),  GC: 
end-class 


EMPTY-SET; 
GUN-CLASS)  in(G, 
GUN-CLASS)  in(G, 
GUN-CLASS)  in(G, 
GUN-CLASS)  in(G. 
GUN-CLASS)  in(G, 


GC)  <=>  in (REPLACE-GUN (G),  REPLACE-GUN(GC)) ; 

GC)  <=>  in(CUT-OFF-SUPPLY(G) ,  CUT-OFF-SUPPLY(GC)) ; 
GC)  <=>  in(DEPRESS-TRIGGER(G) ,  DEPRESS-TRIGGER(GC) ) ; 
GC)  <=>  in(RELEASE-TRIGGER(G) ,  RELEASE-TRIGGER(GC)) ; 
GC)  <=>  in(REMOVE-GUN(G),  REMOVE-GUN  (GO) 


class  DISPLAY  is 
class-sort  DISPLAY 
import  GRADE,  AMOUNT,  VOLUME 
sort  DISPLAY-STATE 

operations  ATTR-EQUAL:  DISPLAY,  DISPLAY  ->  BOOLEAN 
attributes 

COST:  DISPLAY  ->  AMOUNT 
VOLUME:  DISPLAY  ->  VOLUME 
PPG:  DISPLAY  ->  AMOUNT 
GRADE:  DISPLAY  ->  GRADE 

state-attributes  DISPLAY-STATE:  DISPLAY  ->  DISPLAY-STATE 
methods 

CREATE-DISPLAY:  ->  DISPLAY 

UPDATE-DISPLAY:  DISPLAY,  COST,  VOLUME  ->  DISPLAY 
ZERO-OUT-DISPLAY:  DISPLAY  ->  DISPLAY 
states 

ZERO-DISPLAY:  ->  DISPLAY-STATE 
INCREMENT-DISPLAY:  ->  DISPLAY-STATE 
events 

RESET-DISPLAY:  DISPLAY  ->  DISPLAY 
PULSE:  DISPLAY  ->  DISPLAY 
NEW-DISPLAY:  ->  DISPLAY 
eixioms 

ZERO-DISPLAY  <>  INCREMENT-DISPLAY; 

ATTR-EQUAL (Dl,  D2)  <=>  (GRADE(Dl)  =  GRADE(D2)  &  VOLUME(Dl)  =  V0LUME(D2) 

k  COST(Dl)  =  C0ST(D2)); 

DISPLAY-STATE(D)  =  ZERO-DISPLAY  =>  COST(D)  =  0  &  VOLUME(D)  =  0; 
DISPLAY-STATE(D)  =  INCREMENT-DISPLAY  =>  COST(D)  >=  0  &  VDLUME(D)  >=  0; 
COST(D)  >=  0; 

VOLUME  (D)  >=  0; 

PPG(D)  =  COST(D)  /  VOLUME(D); 

VOLUME(CREATE-DISPLAY(D))  =  0; 

COST(CREATE-DISPLAY(D))  =  0; 

GRADE (UPDATE-DISPLAY (D))  =  GRADE(D); 

VOLUME (UPDATE-DISPLAY (D))  =  VOLUME(D)  +  1; 
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COST(UPDATE-DISPUY(D))  =  COST(D)  +  1; 

GRADE(ZERO-OUT-DISPLAY(D))  =  GRADE(D): 

COST(ZERO-OUT-DISPLAY(D))  =  0; 

VOLUME(ZERO-OUT-DISPLAY(D))  =  0; 

(DISPLAY-STATE(NEW-DISPLAY(D))  =  ZERO-DISPLAY 

6  ATTR-EQUAL(NEW-DISPLAY(D),  CREATE-DISPLAY(D))) ; 

(DISPLAY-STATE (D)  =  ZERO-DISPLAY)  =>  (DISPLAY-STATE(PULSE(D) )  =  INCREMENT-DISPLAY 
&  ATTR-EQUAL(PULSE(D).  UPDATE-DISPLAY(D) ) ) j 
(DISPLAY-STATE (D)  =  INCREMENT-DISPLAY) 

=>  (DISPLAY-STATE(RESET-DISPLAY(D))  =  ZERO-DISPLAY 

&  ATTR-EQUAL(RESET-DISPLAY(D),  ZERO-OUT-DISPLAY(D))) ; 
(DISPLAY-STATE (D)  =  INCREMENT-DISPLAY)  =>  (DISPLAY-STATE(PULSE(D) )  =  INCREMENT-DISPLAY 
ft  ATTR-EQUAL (PULSE (D),  UPDATE-DISPLAY(D) ) ) ; 

DISPLAY-STATE(D)  =  ZERO-DISPLAY  =>  DISPLAY-STATE(RESET-DISPLAY(D) )  =  ZERO-DISPLAY; 
DISPLAY-STATE (D)  =  ZERO-DISPLAY  =>  DISPLAY-STATE(PULSE(D) )  =  ZERO-DISPLAY; 
DISPLAY-STATE(D)  =  INCREMENT-DISPLAY  =>  DISPLAY-STATE(PULSE(D) )  =  INCREMENT-DISPLAY; 
end-class 


class  DISPLAY-CLASS  is 
class-sort  DISPLAY-CLASS 
contained-class  DISPLAY 
events 

RESET-DISPLAY:  DISPLAY-CLASS  ->  DISPLAY-CLASS 
PULSE:  DISPLAY-CLASS  ->  DISPLAY-CLASS 
NEW-DISPLAY-CLASS:  ->  DISPLAY-CLASS 
aucioms 

NEW-DISPLAY-CLASS ()  =  EMPTY-SET; 

fa  (D:DISPLAY,  DC: DISPLAY-CLASS)  in(D,  DC)  <=>  in(PULSE(D),  PULSE(DC)); 
fa  (D:DISPLAY,  DC: DISPLAY-CLASS)  in(D,  DC)  <=>  in(RESET-DISPLAY(D) ,  RESET-DISPLAY(DC)) ; 
end-class 


class  CLUTCH-MOTOR-ASSEMBLY  is 
class-sort  CLUTCH-MOTOR-ASSEMBLY 
import  CLUTCH-MOTOR-ASSEMBLY-AGGREGATE 
attributes 

MOTOR-OBJ:  CLUTCH-MOTOR-ASSEMBLY  ->  MOTOR-CLASS 

CLUTCH-OBJ:  CLUTCH-MOTOR-ASSEMBLY  ->  CLUTCH-CLASS 
methods 

CREATE-CLUTCH-MOTOR- ASSEMBLY:  ->  CLUTCH-MOTOR-ASSEMBLY 
events  NEW-CLUTCH-MOTOR-ASSEMBLY :  ->  CLUTCH-MOTOR-ASSEMBLY 
axioms 

ATTR-EQUAL(C1,  C2)  <=>  (CLUTCH-OBJ (Cl)  =  CLUTCH-OBJ (C2) 

ft  MOTOR-OBJ(Cl)  =  M0T0R-0BJ(C2)): 

ATTR-EQUAL(NEW-CLUTCH-MOTOR-ASSEMBLY() ,  CREATE-CLUTCH-MOTOR-ASSEMBLYO)  ; 

SIZE(CLUTCH-OBJ(C))  =  1; 

SIZE(MOTOR-OBJ(C))  =  1 
end-class 


class  CLUTCH-MOTOR-ASSEMBLY-CLASS  is 
class-sort  CLUTCH-MOTOR-ASSEMBLY-CLASS 
contained-class  CLUTCH-MOTOR-ASSEMBLY 
events 

NEW-CLUTCH-MOTOR- ASSEMBLY-CLASS :  ->  CLUTCH-MOTOR-ASSEMBLY-CLASS 
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axioms  NEW-CLUTCH-MOTOR-ASSEMBLY-CLASS()  =  EMPTY-SET 
end-class 


aggregate  CLUTCH-MOTOR-ASSEMBLY-AGGREGATE  is 

nodes  DISABLE-CLUTCH,  FREE-CLUTCH,  MOTOR-CLASS,  MOTOR,  START-FUEL, 
CLUTCH-CLASS,  CLUTCH 

arcs  DISABLE-CLUTCH  ->  CLUTCH:  {DISABLE-CLUTCH-SORT  ->  CLUTCH}, 
FREE-CLUTCH  ->  CLUTCH:  {FREE-CLUTCH-SORT  ->  CLUTCH}, 

MOTOR  ->  MOTOR-CLASS:  {},  CLUTCH  ->  CLUTCH-CLASS:  {}, 
DISABLE-CLUTCH  ->  MOTOR:  {},  FREE-CLUTCH  ->  MOTOR:  {}, 
START-FUEL  ->  CLUTCH:  {} 
end-aggregate 


class  GUN-HOLSTER-ASSEMBLY  is 
class-sort  GUN-HOLSTER-ASSEMBLY 
import  GUN-HOLSTER-ASSEMBLY-AGGREGATE 
attributes 

GUN-OBJ:  GUN-HOLSTER-ASSEMBLY  ->  GUN-CLASS 

HOLSTER-OBJ:  GUN-HOLSTER- ASSEMBLY  ->  HOLSTER-CLASS 
methods  CREATE-GUN-HOLSTER-ASSEMBLY :  ->  GUN-HOLSTER-ASSEMBLY 
events  NEW-GUN-HOLSTER- ASSEMBLY :  ->  GUN-HOLSTER-ASSEMBLY 
2Lxioms 

ATTR-EQUAL(G1,  G2)  <=>  (HOLSTER-OBJ (Gl)  =  HOLSTER-OBJ (G2)  &  GUN-OBJ(Gl)  =  GUN-0BJ(G2)) 

ATTR-EQUAL (NEW-GUN-HOLSTER-ASSEMBLY ( ) ,  CREATE-GUN-HOLSTER-ASSEMBLY ( ) ) ; 

SIZE(HOLSTER-OBJ(G))  =  1; 

SIZE(GUN-OBJ(G))  =  1 
end-class 


class  GUN-HOLSTER-ASSEMBLY-CLASS  is 
class-sort  GUN-HOLSTER-ASSEMBLY-CLASS 
cont ained- class  GUN-HOLSTER- ASSEMBLY 

events  NEW-GUN-HOLSTER-ASSEMBLY-CLASS:  ->  GUN-HOLSTER-ASSEMBLY-CLASS 
axioms  NEW-GUN-HOLSTER-ASSEMBLY-CLASS()  =  EMPTY-SET 
end- class 


aggregate  GUN-HOLSTER-ASSEMBLY-AGGREGATE  is 
nodes  RELEASE-HOLSTER-SWITCH,  FREE-CLUTCH,  ENGAGE-CLUTCH, 

CLOSE-HOLSTER-SWITCH,  DISABLE-PUMP,  START-TIMER,  GUN-CLASS, 

GUN,  HOLSTER-CLASS,  HOLSTER 

arcs  RELEASE-HOLSTER-SWITCH  ->  HOLSTER:  {RELEASE-HOLSTER-SWITCH-SORT  ->  HOLSTER}, 
CLOSE-HOLSTER-SWITCH  ->  HOLSTER:  {CLOSE-HOLSTER-SWITCH-SORT  ->  HOLSTER}, 

GUN  ->  GUN-CLASS:  {}, 

HOLSTER  ->  HOLSTER-CLASS:  {}, 

RELEASE-HOLSTER-SWITCH  ->  GUN:  {}, 

FREE-CLUTCH  ->  GUN:  {}, 

ENGAGE-CLUTCH  ->  GUN:  {}, 

CLOSE-HOLSTER-SWITCH  ->  GUN:  {}, 

DISABLE-PUMP  ->  GUN:  {}, 

START-TIMER  ->  GUN:  {} 
end-aggregate 
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class  PUMP  is 
class-sort  PUMP 

import  PUMP-ID,  RESET-DISPLAY.  START-PUMP-MOTOR,  PUMP-AGGREGATE 
sort  PUMP-STATE  operations  ATTR-EQUAL:  PUMP,  PUMP  ->  BOOLEAN 
attributes 

PUMP-ID:  PUMP  ->  PUMP-ID 

GUN-HOLSTER-ASSEMBLY-OBJ:  PUMP  ->  GUN-HOLSTER-ASSEMBLY-CLASS 
CLUTCH-MOTOR- ASSEMBLY-OBJ : 

PUMP  ->  CLUTCH-MOTOR-ASSEMBLY-CLASS 
DISPLAY-OBJ:  PUMP  ->  DISPLAY-CLASS 
START-PUMP-MOTOR-OBJ;  PUMP  ->  START-PUMP-MOTOR-SORT 
RESET-DISPLAY-OB J :  PUMP  ->  RESET-DISPLAY-SORT 
state-attributes  PUMP-STATE:  PUMP  ->  PUMP-STATE 
methods 

CREATE-PUMP:  PUMP-ID  ->  PUMP 
ENABLE-PUMP:  PUMP  ->  PUMP 
states 

PUMP-DISABLED:  ->  PUMP-STATE 
PUMP-ENABLED:  ->  PUMP-STATE 
events 

ENABLE-PUMP:  PUMP,  PUMP-ID  ->  PUMP 
NEW-PUMP:  PUMP-ID  ->  PUMP 
DISABLE-PUMP:  PUMP  ->  PUMP 
axioms 

PUMP-DISABLED  <>  PUMP-ENABLED; 

ATTR-EQUAL (PI,  P2)  <=> 

(PUMP-ID(Pl)  =  PUMP-ID(P2)  &  RESET-DISPLAY-OBJ(Pl)  =  RESET-DISPLAY-OB J(P2) 

&  START-PUMP-MOTOR-OBJ (PI)  =  START-PUMP-MOTOR-OBJ (P2) 

&  DISPLAY-OBJ(Pl)  =  DISPLAY-OBJ (P2) 

&  CLUTCH-MOTOR- ASSEMBLY-OBJ (PI)  =  CLUTCH-M0T0R-ASSEMBLY-0BJ(P2) 

&  GUN-HOLSTER-ASSEMBLY-OBJ (PI)  =  GUN-HOLSTER-ASSEMBLY-OBJ (P2) ) ; 
(PUMP-STATE(P)  =  PUMP-ENABLED)  =>  (PUMP-STATE(DISABLE-PUMP(P))  =  PUMP-DISABLED); 
(PUMP-STATE(NEW-PUMP(P,  A))  =  PUMP-DISABLED 

&  ATTR-EQUAL (NEW-PUMP (P,  A),  CREATE-PUMP (P,  A))); 

(PUMP-STATE(P)  =  PUMP-DISABLED  &(X  =  PUMP-ID(P))) 

=>  (PUMP-STATE (ENABLE-PUMP (P,  X))  =  PUMP-ENABLED 

&  RESET-DISPLAY-OBJ(ENABLE-PUMP(P,  X))  =  RESET-DISPLAY(RESET-DISPLAY-OBJ(P) ) 
6  START-PUMP-MOTOR-OBJ (ENABLE-PUMP(P,  X)) 

=  START-PUMP-MOTOR(START-PUMP-MDTOR-OBJ(P) ) ) ; 

(PUMP-STATE(P)  =  PUMP-DISABLED  &(X  <>  PUMP-ID(P))) 

=>  PUMP-STATE  (ENABLE-PUMP  (P,  X))  =  PUMP-DISABLED; 

PUMP-STATE(P)  =  PUMP-DISABLED  =>  PUMP-STATE(DISABLE-PUMP(P))  =  PUMP-DISABLED; 
PUMP-STATE(P)  =  PUMP-ENABLED  =>  PUHP-STATE(ENABLE-PUMP(P,  X))  =  PUMP-ENABLED 
end-class 


class  REGULAR  is 
class-sort  REGULAR  <  PUMP 
import  PUMP 

methods  CREATE-REGULAR :  ->  REGULAR 
events  NEW-REGULAR:  ->  REGULAR 

axioms  ATTR-EQUAL(NEW-REGULAR()  ,  CREATE-REGULARO) 
end-class 
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class  REGULAR-CLASS  is 
class-sort  REGULAR-CLASS 
contained-class  REGULAR 
import  PUMP-CLASS 

events  NEW-REGULAR-CLASS:  ->  REGULAR-CLASS 
axioms  NEW-REGULAR-CLASS 0  =  EMPTY-SET 
end-class 


class  SOPHISTICATED  is 
class-sort  SOPHISTICATED  <  PUMP 
import  PUMP 

operations  ATTR-EQUAL:  SOPHISTICATED,  SOPHISTICATED  ->  BOOLEAN 
attributes 

VOLUME-SELECT:  SOPHISTICATED  ->  VOLUME 

AMOUNT-SELECT:  SOPHISTICATED  ->  AMOUNT 
methods 

CREATE-SOPHISTICATED:  ->  SOPHISTICATED 
events 

NEW-SOPHISTICATED:  ->  SOPHISTICATED 
axioms 

ATTR-EQUAL (SI.  S2)  <=>  (PUMP. ATTR-EQUAL (SI,  S2) 

&  AMOUNT-SELECT (SI)  =  AM0UNT-SELECT(S2)  &  VOLUME-SELECT(Sl)  =  V0LUME-SELECT(S2) ) ; 

AMOUNT-SELECT(CREATE-SOPHISTICATED(S))  =  0; 

VOLUME-SELECT(CREATE-SOPHISTICATED(S))  =  0; 

ATTR-EQUAL (NEW-SOPHISTICATED ( ) ,  CREATE-SOPHISTICATED ( ) ) 
end- class 


class  SOPHISTICATED-CLASS  is 
class-sort  SOPHISTICATED-CLASS 
contained-class  SOPHISTICATED 
import  PUMP-CLASS 

events  NEW-SOPHISTICATED-CLASS:  ->  SOPHISTICATED-CLASS 
axioms  NEW-SOPHISTICATED-CLASS ()  =  EMPTY-SETend-class 


class  PUMP-CLASS  is 

class-sort  PUMP-CLASS  contained-class  PUMP 
events 

ENABLE-PUMP:  PUMP-CLASS,  PUMP-ID  ->  PUMP-CLASS 
DISABLE-PUMP:  PUMP-CLASS  ->  PUMP-CLASS 
NEW-PUMP-CLASS:  ->  PUMP-CLASS 
aixioms 

NEW-PUMP-CLASS  0  =  EMPTY-SET; 

fa  ((P:  PUMP),  PC:  PUMP-CLASS)  in(P,  PC)  <=>  in(DISABLE-PUMP(P) ,  DISABLE-PUMP (PC) ) ; 
fa  ((P:  PUMP),  (PC:  PUMP-CLASS),  X:  PUMP-ID)  in(P,  PC) 

<=>  in(ENABLE-PUMP(P,  X),  ENABLE-PUMP (PC,  X)) 
end-class 


aggregate  PUMP-AGGREGATE  is 

nodes  FREE-CLUTCH,  ENGAGE-CLUTCH,  GUN-HOLSTER- ASSEMBLY- AGGREGATE , 
GUN-HOLSTER- ASSEMBLY-CLASS ,  GUN-HOLSTER-ASSEMBLY , 
CLUTCH-MOTOR-ASSEMBLY-AGGREGATE ,  CLUTCH-MOTOR-ASSEMBLY-CLASS , 
CLUTCH-MOTOR-ASSEMBLY,  GRADE,  AMOUNT,  VOLUME.  DISPLAY-CLASS, 
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DISPLAY 

arcs  FREE-CLUTCH  ->  GUN-HOLSTER-ASSEMBLY- AGGREGATE :  {}, 

FREE-CLUTCH  ->  CLUTCH-MOTOR- ASSEMBLY- AGGREGATE:  {}. 

FREE-CLUTCH  ->  CLUTCH-MOTOR- ASSEMBLY- AGGREGATE:  {FREE-CLUTCH-SORT  ->  CLUTCH}, 
ENGAGE-CLUTCH  ->  GUN-HOLSTER-ASSEMBLY-AGGREGATE:  {}, 

ENGAGE-CLUTCH  ->  CLUTCH-MOTOR- ASSEMBLY- AGGREGATE:  {ENGAGE-CLUTCH-SORT  ->  CLUTCH}, 
GUN-HOLSTER-ASSEMBLY-AGGREGATE  ->  GUN-HOLSTER-ASSEMBLY:  {}, 

GUN-HOLSTER-ASSEMBLY  ->  GUN-HOLSTER-ASSEMBLY-CLASS:  {}, 

CLUTCH-MOTOR- ASSEMBLY-AGGREGATE  ->  CLUTCH-MOTOR-ASSEMBLY:  {}, 
CLUTCH-MOTOR-ASSEMBLY  ->  CLUTCH-MOTOR-ASSEMBLY-CLASS:  {}, 

DISPLAY  ->  DISPLAY-CLASS:  {}, 

GRADE  ->  DISPLAY:  {}, 

AMOUNT  ->  DISPLAY:  {}, 

VOLUME  ->  DISPLAY:  {} 
end-aggregate 


aggregate  DOMAIN-THEORY-AGGREGATE  is 

nodes  DISABLE-PUMP,  REGULAR-CLASS,  REGULAR,  SOPHISTICATED-CLASS, 
SOPHISTICATED,  PUMP-ID,  START-PUMP-MOTOR,  RESET-DISPLAY, 
PUMP-AGGREGATE,  PUMP-CLASS,  PUMP 
arcs  DISABLE-PUMP  ->  PUMP:  {DISABLE-PUMP-SORT  ->  PUMP}, 

DISABLE-PUMP  ->  PUMP-AGGREGATE :  {}. 

REGULAR  ->  REGULAR-CLASS:  {}, 

SOPHISTICATED  ->  SOPHISTICATED-CLASS:  {}, 

START-PUMP-MOTOR  ->  PUMP-AGGREGATE :  {START-PUMP-MOTOR-SORT  ->  MOTOR}, 
RESET-DISPLAY  ->  PUMP-AGGREGATE :  {RESET-DISPLAY-SORT  ->  DISPLAY}, 
PUMP-AGGREGATE  ->  PUMP:  {}, 

PUMP  ->  PUMP-CLASS:  {}, 

PUMP-ID  ->  PUMP:  {}, 

START-PUMP-MOTOR  ->  PUMP:  {}, 

RESET-DISPLAY  ->  PUMP:  {}, 

PUMP-CLASS  ->  REGULAR-CLASS:  {}, 

PUMP  ->  REGULAR:  {}, 

PUMP-CLASS  ->  SOPHISTICATED-CLASS:  {}, 

PUMP  ->  SOPHISTICATED:  {} 
end-aggregate 


event  START-FUEL  is 
class-sort  START-FUEL-SORT 

events  START-FUEL:  START-FUEL-SQRT  ->  START-FUEL-SORT 
end-event 


event  FREE-CLUTCH  is 
class-sort  FREE-CLUTCH-SORT 

events  FREE-CLUTCH:  FREE-CLUTCH-SORT  ->  FREE-CLUTCH-SORT 
end-event 


event  DISABLE-CLUTCH  is 
class-sort  DISABLE-CLUTCH-SORT 

events  DISABLE-CLUTCH:  DISABLE-CLUTCH-SORT  ->  DISABLE-CLUTCH-SORT 
end-event 
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event  ENGAGE-CLUTCH  is 
class-sort  ENGAGE-CLUTCH-SORT 

events  ENGAGE-CLUTCH:  ENGAGE-CLUTCH-SQRT  ->  ENGAGE-CLUTCH-SORT 
end-event 


event  START-TIMER  is 
class-sort  START-TIMER-SORT 

events  START-TIMER:  START-TIMER-SORT  ->  START-TIMER-SORT 
end-event 


event  CLOSE-HOLSTER-SWITCH  is 
class-sort  CLOSE-HOLSTER-SWITCH-SORT 
events 

CLOSE-HOLSTER-SWITCH:  CLOSE-HOLSTER-SWITCH-SORT  ->  CLOSE-HOLSTER-SWITCH-SORT 
end-event 


event  RELEASE-HOLSTER-SWITCH  is 
class-sort  RELEASE-HOLSTER-SWITCH-SORT 

events  RELEASE-HOLSTER-SWITCH:  RELEASE-HOLSTER-SWITCH-SORT  ->  RELEASE-HOLSTER-SWITCH-SORT 
end-event 


event  RESET-DISPLAY  is 
class-sort  RESET-DISPLAY-SORT 

events  RESET-DISPLAY:  RESET-DISPLAY-SORT  ->  RESET-DISPLAY-SORT 
end-event 


event  START-PUMP-MOTOR  is 
class-sort  START-PUMP-MOTOR-SORT 

events  START-PUMP-MOTOR:  START-PUMP-MOTOR-SORT  ->  START-PUMP-MOTOR-SORT 
end-event 


event  DISABLE-PUMP  is 
class-sort  DISABLE-PUMP-SORT 

events  DISABLE-PUMP:  DISABLE-PUMP-SORT  ->  DISABLE-PUMP-SORT 
end-event 


G.2  Faculty  Student  Database  -  Faculty  Workload  Functional  Model 


Figures  G.l  through  G.4  define  the  Faculty  Workload  process.  This  functional  model  is 
translated  into  the  Faculty- Workload  class  in  Section  G.3. 
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Figure  G.l  Faculty  Workload  Functional  Model 


- - — ; 


&{a«d}  'PKTutty^FUMXioaai  MetfttMftitmbfti 


workload 


calculate-faculty-workload 


Facu|ty-Workload 


workload 


crediteiinteger 


calciJale-workiDod 


cakiiate-student-lciad 


Figure  G.2  Calculate-Faculty- Workload  Functional  Model 
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Figure  G.3  Calculate-Student-Load  Functional  Model 


Figure  G.4  Calculate-Course-Load  Functional  Model 
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G.3  Faculty  Student  Database  0-Slang 

class  SECTION  is 
class-sort  SECTION 
import  NUMBER 

operations  ATTR-EQUAL:  SECTION,  SECTION  ->  BOOLEAN 

attributes  NUMBER:  SECTION  ->  NUMBER 

methods  CREATE-SECTION :  ->  SECTION 

events  NEW-SECTION:  ->  SECTION 

cixioms 

ATTR-EQUAL (SI,  S2)  <=>  (NUMBER(Sl)  =  NUMBER(S2)): 
ATTR-EQUAL(NEW-SECTI0NO  ,  CREATE-SECTIONO) 
end-class 


class  SECTION-CLASS  is 
class-sort  SECTION-CLASS 
contained-class  SECTION 
events  NEW-SECTION-CLASS:  ->  SECTION-CLASS 
axioms  NEW-SECTION-CLASS O  =  EMPTY-SET 
end-class 


class  A-CLASS  is 
class-sort  A-CLASS 
import  PROGRAM 

operations  ATTR-EQUAL:  A-CLASS,  A-CLASS  ->  BOOLEAN 

attributes  PROGRAM:  A-CLASS  ->  PROGRAM 

methods  CREATE- A-CLASS :  ->  A-CLASS 

events  NEW-A-CLASS:  ->  A-CLASS 

axioms 

ATTR-EQUAL(A1,  A2)  <=>  (PROGRAM(Al)  =  PR0GRAM(A2)) ; 

ATTR-EQUAL (NEW-A-CLASS ( ) ,  CREATE- A-CLASS  0 ) 
end-class 


class  A-CLASS-CLASS  is 
class-sort  A-CLASS-CLASS 
contained-class  A-CLASS 
events  NEW-A-CLASS-CLASS :  ->  A-CLASS-CLASS 
axioms  NEW-A-CLASS-CLASS 0  =  EMPTY-SET 
end-class 


class  QUARTER  is 
class-sort  QUARTER 

import  END-DATE,  START-DATE,  QUATER-YEAR,  QUARTER-NAME 
operations  ATTR-EQUAL:  QUARTER,  QUARTER  ->  BOOLEAN 
attributes 

QUARTER-NAME:  QUARTER  ->  QUARTER-NAME 
QUATER-YEAR:  QUARTER  ->  QUATER-YEAR 
START-DATE:  QUARTER  ->  START-DATE 
END-DATE:  QUARTER  ->  END-DATE 
methods  CREATE- QUARTER:  ->  QUARTER 
events  NEW-QUARTER:  ->  QUARTER 
axioms 
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ATTR-EQUAL(Q1,  Q2)  <=>  (END-DATE(Ql)  =  END-DATE(Q2) 

&  START-DATE (Ql)  =  START-DATE (Q2) 

&  QUATER-YEAR(Ql)  =  QUATER-YEAR(Q2) 

&  QUARTER-NAME (Ql)  =  QUARTER-NAME(Q2)) ; 
ATTR-EQUAL(NEW-QUARTER()  ,  CREATE-QUARTERO) 
end-class 


class  QUARTER-CLASS  is 
class-sort  QUARTER-CLASS 
contained-class  QUARTER 
events  NEW-QUARTER-CLASS:  ->  QUARTER-CLASS 
axioms  NEW-QUARTER-CLASS  0  =  EMPTY-SET 
end-class 


class  COURSE  is 
class-sort  COURSE 

import  ABET-OTHER,  ABET-MATH,  ABET-SCIENCE,  ABET-DESIGN,  LAB-HOURS, 

LEXTURE-HOURS,  CREDIT-HOURS,  DESCRIPTION,  TITLE,  NUM,  TYPE 
operations  ATTR-EQUAL:  COURSE,  COURSE  ->  BOOLEAN 
attributes 

TYPE:  COURSE  ->  TYPE 
NUM:  COURSE  ->  NUM 
TITLE:  COURSE  ->  TITLE 
DESCRIPTION:  COURSE  ->  DESCRIPTION 
CREDIT-HOURS:  COURSE  ->  CREDIT-HOURS 
LEXTURE-HOURS:  COURSE  ->  LEXTURE-HOURS 
LAB-HOURS:  COURSE  ->  LAB-HOURS 
ABET-DESIGN:  COURSE  ->  ABET-DESIGN 
ABET-SCIENCE:  COURSE  ->  ABET-SCIENCE 
ABET-MATH:  COURSE  ->  ABET-MATH 
ABET-OTHER:  COURSE  ->  ABET-OTHER 
methods  CREATE-COURSE :  ->  COURSE 
events  NEW-COURSE:  ->  COURSE 
axioms 

ATTR-EQUAL(C1,  C2)  <=>  (ABET-OTHER (Cl)  =  ABET-OTHER (C2) 

&  ABET-MATH(Cl)  =  ABET-MATH(C2) 
ft  ABET-SCIENCE(Cl)  =  ABET-SCIENCE (C2) 
ft  ABET-DESIGN (Cl)  =  ABET-DESIGN (C2) 
ft  LAB-HOURS(Cl)  =  LAB-H0URS(C2) 
ft  LEXTURE-HOURS (Cl)  =  LEXTURE-HOURS (C2) 
ft  CREDIT-HOURS (Cl)  =  CREDIT-HOURS (C2) 

ft  DESCRIPTION (Cl)  =  DESCRIPTI0N(C2)  ft  TITLE(Cl)  =  TITLE(C2) 
ft  NUM(Cl)  =  NUM(C2)  ft  TYPE(Cl)  =  TYPE(C2)): 

ATTR-EQUAL (NEW-COURSE 0 ,  CREATE-COURSE ()) 
end-class 


class  COURSE-CLASS  is 

class-sort  COURSE-CLASS  contained-class  COURSE 
events  NEW-COURSE-CLASS:  ->  COURSE-CLASS 
axioms  NEW-COURSE-CLASS ()  =  EMPTY-SET 
end- class 
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class  FACULTY  is 
class-sort  FACULTY 

import  ACADEMIC-RANK,  SEX,  SSAN,  AGE,  BIRTHDATE,  FIRSTNAME, 

INITIAL,  LAST-NAME 

operations  ATTR-EQUAL:  FACULTY,  FACULTY  ->  BOOLEAN 
attributes 

LAST-NAME:  FACULTY  ->  LAST-NAME 
INITIAL:  FACULTY  ->  INITIAL 
FIRSTNAME:  FACULTY  ->  FIRSTNAME 
BIRTHDATE:  FACULTY  ->  BIRTHDATE 
AGE:  FACULTY  ->  AGE 
SSAN:  FACULTY  ->  SSAN 
SEX:  FACULTY  ->  SEX 

ACADEMIC-RANK:  FACULTY  ->  ACADEMIC-RANK 
methods  CREATE-FACULTY :  ->  FACULTY 
events  NEW-FACULTY:  ->  FACULTY 
axioms 

ATTR-EQUAL (FI,  F2)  <=>  (ACADEMIC-RANK (FI)  =  ACADEMIC-RANK(F2) 

<t  SEX  (FI)  =  SEX  (F2)  &  SSAN(Fl)  =  SSAN(F2) 

&  BIRTHDATE(Fl)  =  BIRTHDATE(F2)  &  FIRSTNAME(Fl)  =  FIRSTNAME(F2) 
Sc.  INITIAL(Fl)  =  INITIAL(F2)  &  LAST-NAME(Fl)  =  LAST-NAME(F2) ) ; 
ATTR-EQUAL (NEW-FACULTY ( ) ,  CREATE-FACULTY ( ) ) 
end-class 


class  FACULTY-CLASS  is 
class-sort  FACULTY-CLASS 
contained-class  FACULTY 
events  NEW-FACULTY-CLASS:  ->  FACULTY-CLASS 
axioms  NEW-FACULTY-CLASS ()  =  EMPTY-SET 
end-class 


class  STUDENT  is 
class-sort  STUDENT 

import  GPA,  WEIGHT,  HEIGHT,  SEX,  SSAN,  AGE,  BIRTH-DATE,  FIRST-NAME, 

INIT,  LASTNAME 

operations  ATTR-EQUAL:  STUDENT,  STUDENT  ->  BOOLEAN 
attributes 

LASTNAME:  STUDENT  ->  LASTNAME 
INIT:  STUDENT  ->  INIT 
FIRST-NAME:  STUDENT  ->  FIRST-NAME 
BIRTH-DATE:  STUDENT  ->  BIRTH-DATE 
AGE:  STUDENT  ->  AGE 
SSAN:  STUDENT  ->  SSAN 
SEX:  STUDENT  ->  SEX 
HEIGHT:  STUDENT  ->  HEIGHT 
WEIGHT:  STUDENT  ->  WEIGHT 
GPA:  STUDENT  ->  GPA 
methods  CREATE-STUDENT :  ->  STUDENT 
events  NEW-STUDENT:  ->  STUDENT 
axioms 

ATTR-EQUAL (SI,  S2)  <=>  (GPA(Sl)  =  GPA(S2)  &  WEIGHT(Sl)  =  WEIGHT(S2) 

Sc  HEIGHT(Sl)  =  HEIGHT(S2)  Sc  SEX  (SI)  =  SEX  (S2) 

Sc  SSAN(Sl)  =  SSAN(S2)  Sc  BIRTH-DATE  (SI)  =  BIRTH-DATE  (S2) 
&  FIRST-NAME(Sl)  =  FIRST-NAME (S2)  Sc  INIT(Sl)  =  INIT(S2) 
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&  LASTNAME(Sl)  =  LASTNAME(S2) ) ; 
ATTR-EQUAL(NEW-STUDENT<)  ,  CREATE-STUDENTO) 
end-class 


class  STUDENT-CLASS  is 
class-sort  STUDENT-CLASS 
contained-class  STUDENT 
events  NEW-STUDENT-CLASS:  ->  STUDENT-CLASS 
axioms  NEW-STUDENT-CLASS ()  =  EMPTY-SET 
end- class 


class  FACULTY-WORKLOAD  is 
class-sort  FACULTY-WORKLOAD 
import  FACULTY-WORKLOAD-AGGREGATE 
operations 

ATTR-EQUAL:  FACULTY-WORKLOAD,  FACULTY-WORKLOAD  ->  BOOLEAN 
GET-SECTIONS:  TEACHING,  FACULTY  ->  SECTION-CLASS 
COMPUTE-CREDITS:  TAUGHT- AS,  SECTION-CLASS  ->  INTEGER 
CALCULATE-COURSE-LOAD:  FACULTY-WORKLOAD,  FACULTY  ->  INTEGER 
GET-STUDENTS-ADVISED :  ADVISES,  FACULTY  ->  STUDENT-CLASS 
COUNT-STUDENTS:  MEMBER-OF,  STUDENT-CLASS  ->  INTEGER 
CALCULATE-STUDENT-LOAD :  FACULTY-WORKLOAD,  FACULTY  ->  INTEGER,  INTEGER 
CALCULATE-WORKLOAD :  INTEGER,  INTEGER,  INTEGER  ->  WORKLOAD 
CALCULATE-FACULTY-WORKLOAD:  FACULTY-WORKLOAD,  NAME  ->  WORKLOAD 
GET-FACULTY:  FACULTY-CLASS,  NAME,  NAME  ->  FACULTY 
GET-COURSE:  COURSE-CLASS,  NUM,  TYPE  ->  COURSE 
GET-SECTIONS-TAUGHT:  SECTION-CLASS,  FACULTY  ->  SECTION-CLASS 
GET-SECTIONS-OFFERED:  SECTION-CLASS,  COURSE  ->  SECTION-CLASS 
COMPUTE-SECTION-UNION:  SECTION-CLASS,  SECTION-CLASS  ->  TIMES-TAUGHT 
COUNT-TIMES-TAUGHT:  SECTION-CLASS,  COURSE,  FACULTY  ->  TIMES-TAUGHT 
GET-TEACHES:  TEACHES,  FACULTY,  COURSE  ->  TEACHES-LINK 
attributes 

STUDENT-OBJ:  FACULTY-WORKLOAD  ->  STUDENT-CLASS 
FACULTY-OBJ:  FACULTY-WORKLOAD  ->  FACULTY-CLASS 
SECTION-OBJ:  FACULTY-WORKLOAD  ->  SECTION-CLASS 
COURSE-OBJ:  FACULTY-WORKLOAD  ->  COURSE-CLASS 
QUARTER-OBJ:  FACULTY-WORKLOAD  ->  QUARTER-CLASS 
A-CLASS-OBJ:  FACULTY-WORKLOAD  ->  A-CLASS-CLASS 
MEMBER-OF-OBJ:  FACULTY-WORKLOAD  ->  MEMBER-OF 
ADVISES-OBJ:  FACULTY-WORKLOAD  ->  ADVISES 
TEACHES-OBJ:  FACULTY-WORKLOAD  ->  TEACHES 
OFFERING-OB J :  FACULTY-WORKLOAD  ->  OFFERING 
TAUGHT-AS-OBJ:  FACULTY-WORKLOAD  ->  TAUGHT- AS 
SCHEDULED-IN-OB J :  FACULTY-WORKLOAD  ->  SCHEDULED-IN 
TEACHING-OB J :  FACULTY-WORKLOAD  ->  TEACHING 
methods 

CREATE-FACULTY-WORKLOAD:  ->  FACULTY-WORKLOAD 
MODIFY-TEACHES:  TEACHES,  TIMES-TAUGHT,  TEACHES-LINK  ->  TEACHES 
UPDATE-TEACHES:  FACULTY-WORKLOAD,  NUM,  NAME,  TYPE  ->  FACULTY-WORKLOAD 
events 

CALCULATE-FACULTY-WORKLOAD-EVENT:  FACULTY-WORKLOAD,  NAME  ->  WORKLOAD 
UPDATE-TEACHES-EVENT:  FACULTY-WORKLOAD,  NUM,  NAME,  TYPE  ->  FACULTY-WORKLOAD 
NEW-FACULTY-WORKLOAD:  ->  FACULTY-WORKLOAD 
axioms 
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ATTR-EQUAL  (FI,  F2)  <=>  (A-CLASS-OBJ  (FI)  =  A-CLASS-OBJ  (F2) 

&  QUARTER-OBJ  (FI)  =  QUARTER-OBJ  (F2) 

&  CQURSE-DBJ  (FI)  =  COURSE-OBJ  (F2) 

&  SECTION-OBJ  (FI)  =  SECTIQN-OBJ  (F2) 

&  FACULTY-OBJ  (FI)  =  FACULTY-OBJ  (F2) 
ft  STUDENT-OBJ  (FI)  =  STUDENT-OBJ  (F2)): 

UPDATE-TEACHES  (F,  NUM,  NAME,  TYPE)  =  FI 

&.  TEACHES-OBJ  (FI)  =  MODIFY-TEACHES  (TEACHES-OBJ  (F) ,  TIMES-TAUGHT,  TEACHES-LIRK) 
&  TEACHES-LINK  =  GET-TEACHES (TEACHES-OBJ  (F) ,  FACULTY,  COURSE) 

&  TIMES-TAUGHT  =  COUNT-TIMES-TAUGHT  (SECTION-OBJ  (F) ,  COURSE,  FACULTY) 

&  COURSE  =  GET-COURSE  (COURSE-OBJ  (F),  NUM,  TYPE) 
k  FACULTY  =  GET-FACULTY  (FACULTY-OBJ  (F),  NAME,  NAME); 

COUNT-TIMES-TAUGHT  (SECTION-OBJ  (F) ,  COURSE,  FACULTY)  =  TIMES-TAUGHT 
k  TIMES-TAUGHT  =  COMPUTE-SECTION-UNION  (C,  F) 

&  C  =  GET-SECTIONS-OFFERED  (SECTION-OBJ  (F) ,  COURSE) 

&  F  =  GET-SECTIONS-TAUGHT  (SECTION-OBJ  (F) ,  FACULTY); 

CALCULATE-FACULTY-WORKLQAD  (F,  NAME)  =  WORKLOAD 
k  WORKLOAD  =  CALCULATE-WORKLOAD  (PHDS,  MS,  CREDITS) 
k  <MS,  PHDS>  =  CALCULATE-STUDENT-LOAD  (F,  FACULTY) 
k  CREDITS  =  CALCULATE-COURSE-LOAD  (F,  FACULTY); 

CALCULATE-STUDENT-LOAD  (F,  FACULTY)  =  <MS,  PHDS> 

&  MS  =  COUNT-STUDENTS  (MEMBER-OF-OBJ  (F) ,  STUDENTS) 
k  STUDENTS  =  GET-STUDENTS-ADVISED  (ADVISES-OBJ  (F),  FACULTY); 

CALCULATE-COURSE-LOAD  (F,  FACULTY)  =  CREDITS 
k  CREDITS  =  COMPUTE-CREDITS  ( TAUGHT- AS-OBJ  (F) ,  SECTIONS) 
k  SECTIONS  =  GET-SECTIONS  (TEACHING-OBJ  (F) ,  FACULTY); 

ATTR-EQUAL  (NEW-FACULTY-WORKLOAD  (),  CREATE-FACULTY-WORKLOAD  ()); 

ATTR-EQUAL  (UPDATE-TEACHES-EVENT  (F,  N,  A,  T) ,  UPDATE-TEACHES  (F,  N,  A,  T)); 

ATTR-EQUAL  (CALCULATE-FACULTY-WORKLOAD-EVENT  (F,  N) , 

CALCULATE-FACULTY-WORKLOAD  (F,  N)) 

end-class 


class  FACULTY-WORKLOAD-CLASS  is 
class-sort  FACULTY-WORKLOAD-CLASS 
contained-class  FACULTY-WORKLOAD 

events  NEW-FACULTY-WORKLOAD-CLASS:  ->  FACULTY-WORKLOAD-CLASS 
axioms  NEW-FACULTY-WORKLOAD-CLASS ( )  =  EMPTY-SET 
end-class 


aggregate  FACULTY-WORKLOAD-AGGREGATE  is 

nodes  MEMBER-OF,  MEMBER-OF-LINK,  ADVISES,  ADVISES-LINK,  TEACHES, 
TEACHES-LINK,  OFFERING,  OFFERING-LINK,  TAUGHT-AS, 

TAUGHT- AS-LINK,  SCHEDULED-IN,  SCHEDULED-IN-LINK,  TEACHING, 
TEACHING-LINK,  GPA,  WEIGHT,  HEIGHT,  BIRTH-DATE,  FIRST-NAME, 
INIT,  LASTNAME,  STUDENT-CLASS,  STUDENT,  ACADEMIC-RANK,  SEX, 
SSAN,  AGE,  BIRTHDATE,  FIRSTNAHE,  INITIAL,  LAST-NAME, 
FACULTY-CLASS,  FACULTY,  NUMBER,  SECTION-CLASS,  SECTION, 
ABET-OTHER,  ABET-MATH,  ABET-SCIENCE,  ABET-DESIGN,  LAB-HOURS, 
LEXTURE-HOURS ,  CREDIT-HOURS,  DESCRIPTION,  TITLE,  NUM,  TYPE, 
COURSE-CLASS,  COURSE, END-DATE,  START-DATE,  QUATER-YEAR, 
QUARTER-NAME,  QUARTER-CLASS,  QUARTER,  PROGRAM,  A-CLASS-CLASS, 
A-CLASS,  TRIV-127:  TRIV,  TRIV-128;  TRIV,  TRIV-129:  TRIV, 
TRIV-130:  TRIV,  TRIV-131:  TRIV,  TRIV-132:  TRIV,  TRIV-133:  TRIV, 
TRIV-134:  TRIV,  TRIV-135:  TRIV,  TRIV- 136:  TRIV,  TRIV-137:  TRIV, 
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TRIV-138:  TRIV,  TRIV-139:  TRIV,  TRIV-140:  TRIV 
arcs  TRIV-140  ->  MEMBER-OF-LINK :  {  E  ->  STUDEHT-OBJ} , 
TRIV-140  ->  STUDENT:  {  E  ->  STUDENT}, 

TRIV-139  ->  MEMBER-OF-LINK:  {  E  ->  A-CLASS-OB J} . 
TRIV-139  ->  A-CLASS:  {  E  ->  A-CLASS}, 
MEMBER-OF-LINK  ->  MEMBER-OF:  {}, 

TRIV-138  ->  ADVISES-LINK:  {  E  ->  FACULTY-OB J} , 
TRIV-138  ->  FACULTY:  {  E  ->  FACULTY}, 

TRIV-137  ->  ADVISES-LINK:  {  E  ->  STUDENT-OB J} , 
TRIV-137  ->  STUDENT:  {  E  ->  STUDENT}, 

ADVISES-LINK  ->  ADVISES:  {}, 

TRIV-136  ->  TEACHES-LINK:  {  E  ->  COURSE-OBJ}, 
TRIV-136  ->  COURSE:  {  E  ->  COURSE}, 

TRIV- 135  ->  TEACHES-LINK:  {  E  ->  FACULTY-OB J} , 
TRIV- 135  ->  FACULTY:  {  E  ->  FACULTY}, 

TEACHES-LINK  ->  TEACHES:  {}, 

TRIV- 134  ->  OFFERING-LINK:  {  E  ->  QUARTER-OBJ}, 
TRIV-134  ->  QUARTER:  {  E  ->  QUARTER}, 

TRIV-133  ->  OFFERING-LINK:  ■[  E  ->  COURSE-OBJ}, 
TRIV-133  ->  COURSE:  {  E  ->  COURSE}, 

OFFERING-LINK  ->  OFFERING:  {}, 

TRIV-132  ->  TAUGHT-AS-LINK:  {  E  ->  SECTION-OBJ}, 
TRIV-132  ->  SECTION:  {  E  ->  SECTION}, 

TRIV-131  ->  TAUGHT-AS-LINK:  {  E  ->  COURSE-OBJ}, 
TRIV-131  ->  COURSE:  {  E  ->  COURSE}, 

TAUGHT-AS-LINK  ->  TAUGHT-AS:  {}, 

TRIV-130  ->  SCHEDULED-IN-LINK:  {  E  ->  SECTION-OBJ}, 
TRIV-130  ->  SECTION:  {  E  ->  SECTION}, 

TRIV-129  ->  SCHEDULED-IN-LINK:  {  E  ->  QUARTER-OBJ}, 
TRIV-129  ->  QUARTER:  {  E  ->  QUARTER}, 
SCHEDULED-IN-LINK  ->  SCHEDULED-IN :  {}, 

TRIV-128  ->  TEACHING-LINK:  {  E  ->  SECTION-OBJ}, 
TRIV-128  ->  SECTION:  {  E  ->  SECTION}, 

TRIV-127  ->  TEACHING-LINK:  {  E  ->  FACULTY-OB J} , 
TRIV-127  ->  FACULTY:  {  E  ->  FACULTY}, 

TEACHING-LINK  ->  TEACHING:  {}, 

STUDENT  ->  STUDENT-CLASS:  {}, 

FACULTY  ->  FACULTY-CLASS:  {}, 

SECTION  ->  SECTION-CLASS:  {}, 

COURSE  ->  COURSE-CLASS:  {}, 

QUARTER  ->  QUARTER-CLASS:  {}, 

A-CLASS  ->  A-CLASS-CLASS :  {}, 

GPA  ->  STUDENT:  <}, 

WEIGHT  ->  STUDENT:  {}, 

HEIGHT  ->  STUDENT:  ^}, 

BIRTH-DATE  ->  STUDENT:  {}, 

FIRST-NAME  ->  STUDENT:  {}, 

INIT  ->  STUDENT:  {}, 

LASTNAME  ->  STUDENT:  {}, 

ACADEMIC-RANK  ->  FACULTY:  {}, 

SEX  ->  STUDENT:  {}, 

SEX  ->  FACULTY:  {}, 

SSAN  ->  STUDENT:  {}, 

SSAN  ->  FACULTY:  {}, 

AGE  ->  STUDENT:  {}, 

AGE  ->  FACULTY:  O, 
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BIRTHDATE  ->  FACULTY:  {}, 
FIRSTNAME  ->  FACULTY:  {}, 
INITIAL  ->  FACULTY:  {}, 
LAST-NAME  ->  FACULTY:  {}, 
NUMBER  ->  SECTION:  {}, 
ABET-OTHER  ->  COURSE:  {}, 
ABET-MATH  ->  COURSE:  {}, 
ABET-SCIENCE  ->  COURSE:  {}. 
ABET-DESIGN  ->  COURSE:  {}, 
LAB-HOURS  ->  COURSE:  {}, 
LEXTURE-HOURS  ->  COURSE:  {}, 
CREDIT-HOURS  ->  COURSE:  {}, 
DESCRIPTION  ->  COURSE:  {}, 
TITLE  ->  COURSE:  {}, 

NUM  ->  COURSE:  {}, 

TYPE  ->  COURSE:  {>, 

END-DATE  ->  QUARTER:  {}, 
START-DATE  ->  QUARTER:  {}, 
QUATER-YEAR  ->  QUARTER:  {}, 
QUARTER-NAME  ->  QUARTER:  {}, 
PROGRAM  ->  A-CLASS:  {} 
end-aggregate 


link  TEACHING-LINK  is 
class-sort  TEACHING-LINK 
sort  SECTION,  FACULTY 

operations  ATTR-EQUAL:  TEACHING-LINK,  TEACHING-LINK  ->  BOOLEAN 
attributes 

FACULTY-OBJ:  TEACHING-LINK  ->  FACULTY 

SECTION-OBJ:  TEACHING-LINK  ->  SECTION 
methods  CREATE-TEACHING-LINK :  FACULTY,  SECTION  ->  TEACHING-LINK 
events  NEW-TEACHING-LINK :  FACULTY,  SECTION  ->  TEACHING-LINK 
axioms 

ATTR-EQUAL(T1,  T2)  <=>  (SECTION-OBJ (Tl)  =  SECTION-OBJ (T2) 

&  FACULTY-OBJ(Tl)  =  FACULTY-OBJ (T2) ) ; 

SECTION-OBJ (CREATE-TEACHING-LINK (T,  S,  F))  =  S; 

FACULTY-OBJ (CREATE-TEACHING-LINK (T,  S,  F))  =  F; 

ATTR-EQUAL(NEH-TEACHING-LINK(T,  S,  F) ,  (CREATE-TEACHING-LINK (T,  S,  F))) 
end-link 


association  TEACHING  is 
class-sort  TEACHING 
link-class  TEACHING-LINK 
sort  SECTION-CLASS,  FACULTY-CLASS 
operations 

IMAGE:  TEACHING,  SECTION  ->  FACULTY-CLASS 
IMAGE:  TEACHING,  FACULTY  ->  SECTION-CLASS 
events  NEW-TEACHING:  ->  TEACHING 
axioms 

NEW-TEACHING 0  =  EMPTY-SET; 

fa  ((S:  TEACHING),  (T:  SECTION),  A:  FACULTY) 

(ex  (F:  TEACHING-LINK)  in(F,  S)  &  TEACHING-OBJ(F)  =  T  &  TEACHING-OBJ(F)  =  A) 
<=>  in(A,  image(S,  T)); 
fa  ((S:  TEACHING),  (T:  SECTION),  A:  FACULTY) 
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(ex  (F:  TEACHING-LINK)  in(F,  S)  &  TEACHING-OBJ(F)  =  A  &  TEACHING-OBJ(F)  =  T) 
<=>  in(T,  image (S,  A)) 
end-association 


link  SCHEDULED-IN-LINK  is 
class-sort  SCHEDULED-IN-LINK 
sort  SECTION,  QUARTER 

operations  ATTR-EQUAL:  SCHEDULED-IN-LINK.  SCHEDULED-IN-LINK  ->  BOOLEAN 
attributes 

QUARTER-OBJ:  SCHEDULED-IN-LINK  ->  QUARTER 
SECTION-OBJ:  SCHEDULED-IN-LINK  ->  SECTION 
methods 


CREATE-SCHEDULED-IN-LINK ; 

QUARTER,  SECTION  ->  SCHEDULED-IN-LINK 
events  NEW-SCHEDULED-IN-LINK :  QUARTER,  SECTION  ->  SCHEDULED-IN-LINK 


axioms 


ATTR-EQUAL (SI,  S2)  <=>  (SECTION-OBJ (SI) 
ft  QUARTER-OBJ (SI) 
SECTION-OBJ (CREATE-SCHEDULED-IN-LINK (S . 
QUARTER-OBJ (CREATE-SCHEDULED-IN-LINK (S . 
ATTR-EQUAL  (NEW-SCHEDULED-IN-LINK(S,  A, 
end-link 


=  SECTION-OBJ (S2) 

=  QUARTER-0BJ(S2)): 

A,  Q))  =  A; 

A.  Q))  =  Q; 

Q),  (CREATE-SCHEDULED-IN-LINK(S, 


A,  Q))) 


association  SCHEDULED-IN  is 
class-sort  SCHEDULED-IN 
link-class  SCHEDULED-IN-LINK 
sort  SECTION-CLASS,  QUARTER-CLASS 
operations 

IMAGE:  SCHEDULED-IN,  SECTION  ->  QUARTER-CLASS 
IMAGE:  SCHEDULED-IN,  QUARTER  ->  SECTION-CLASS 
events  NEW-SCHEDULED-IN :  ->  SCHEDULED-IN 
axioms 

NEW-SCHEDULED-IN ()  =  EMPTY-SET; 

fa  ((S:  SCHEDULED-IN),  A:  SECTION)  SIZE(IMAGE(S,  A))  =  1; 
fa  ((S:  SCHEDULED-IN),  (A:  SECTION),  B:  QUARTER) 

(ex  (Q:  SCHEDULED-IN-LINK)  in(Q,  S)  &  SCHEDULED-IN-DBJ(Q)  =  A 
&  SCHEDULED-IN-OBJ(Q)  =  B)  <=>  in(B,  image(S,  A)); 
fa  ((S:  SCHEDULED-IN),  (A:  SECTION),  B:  QUARTER) 

(ex  (Q:  SCHEDULED-IN-LINK)  in(Q.  S)  &  SCHEDULED-IN-OBJ(Q)  =  B 
&  SCHEDULED-IN-OBJ(Q)  =  A)  <=>  in(A,  image(S,  B)) 
end-association 


link  TAUGHT-AS-LINK  is 
class-sort  TAUGHT-AS-LINK 
sort  SECTION,  COURSE 

operations  ATTR-EQUAL:  TAUGHT-AS-LINK,  TAUGHT-AS-LINK  ->  BOOLEAN 
attributes 

CQURSE-OBJ:  TAUGHT-AS-LINK  ->  COURSE 

SECTION-OBJ:  TAUGHT-AS-LINK  ->  SECTION 
methods  CREATE-TAUGHT-AS-LINK :  COURSE,  SECTION  ->  TAUGHT-AS-LINK 
events  NEW-TAUGHT-AS-LINK :  COURSE,  SECTION  ->  TAUGHT-AS-LINK 
axioms 

ATTR-EQUAL (Tl,  T2)  <=>  (SECTION-QBJ(Tl)  =  SECTION-OBJ (T2) 
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&  CGURSE-QBJ(Tl)  =  COORSE-QBJ(T2) ) ; 
SECTION-QBJ(CREATE-TAUGHT-AS-LINK(T.  S,  O)  =  S; 
COURSE-OBJ(CREATE-TAUGHT-AS-LINK(T.  S.  O)  =  C; 

ATTR-EQUAL(NEW-TAUGHT-AS-LINK(T,  S.  C) ,  (CREATE-TAUGHT-AS-LINK(T,  S,  C))) 
end-link 


association  TAUGHT-AS  is 
class-sort  TAUGHT-AS 
link-class  TAUGHT-AS-LINK 
sort  SECTION-CLASS,  COURSE-CLASS 
operations 

IMAGE:  TAUGHT-AS,  SECTION  ->  COURSE-CLASS 
IMAGE:  TAUGHT-AS,  COURSE  ->  SECTION-CLASS 
events  NEW-TAUGHT-AS :  ->  TAUGHT-AS 
aixioms 

NEW-TAUGHT-AS 0  =  EMPTY-SET; 

fa  ((T:  TAUGHT-AS),  S:  SECTION)  SIZE(IMAGE(T.  S))  =  1; 
fa  ((S:  TAUGHT-AS),  (T:  SECTION),  A:  COURSE) 

(ex  (C:  TAUGHT-AS-LINK)  in(C,  S)  &  TAUGHT-AS-OBJ(C)  =  T  &  TAUGHT-AS-OBJ(C)  =  A) 
<=>  in(A,  image(S,  T)); 
fa  ((S:  TAUGHT-AS),  <T:  SECTION),  A:  COURSE) 

(ex  (C:  TAUGHT-AS-LINK)  in(C,  S)  &  TAUGHT-AS-OBJ(C)  =  A  &  TAUGHT-AS-OBJ(C)  =  T) 
<=>  in(T,  image(S,  A)) 
end-association 


link  OFFERING-LINK  is 
class-sort  OFFERING-LINK 
sort  QUARTER,  COURSE 

operations  ATTR-EQUAL:  OFFERING-LINK,  OFFERING-LINK  ->  BOOLEAN 
attributes 

COURSE-OBJ:  OFFERING-LINK  ->  COURSE 

QUARTER-OBJ:  OFFERING-LINK  ->  QUARTER 
methods  CREATE-OFFERING-LINK :  COURSE,  QUARTER  ->  OFFERING-LINK 
events  NEW-OFFERING-LINK :  COURSE,  QUARTER  ->  OFFERING-LINK 
axioms 

ATTR-EQUAL (01,  02)  <=>  (QUARTER-OBJ (01)  =  QUARTER-OBJ (02) 

&  COURSE-OBJ(Ol)  =  COURSE-OBJ (02)); 

QUARTER-0BJ(CREATE-0FFERING-LINK(0,  Q,  O)  =  Q; 

C0URSE-0BJ(CREATE-0FFERING-LINK(0,  Q,  O)  =  C; 

ATTR-EQUAL(NEH-OFFERING-LINK(0,  Q,  C) ,  (CREATE-0FFERING-LINK(0 ,  Q,  C))) 
end-link 


association  OFFERING  is 
class-sort  OFFERING 
link-class  OFFERING-LINK 
sort  QUARTER-CLASS,  COURSE-CLASS 
operations 

IMAGE:  OFFERING,  QUARTER  ->  COURSE-CLASS 
IMAGE:  OFFERING,  COURSE  ->  QUARTER-CLASS 
events  NEW-OFFERING:  ->  OFFERING 
^Lxioms 

NEW-OFFERING  0  =  EMPTY-SET; 

fa  ((Q:  OFFERING),  (0:  QUARTER),  A:  COURSE) 


G-22 


(ex  (C:  OFFERING-LINK)  in(C,  Q)  &  OFFERING-OBJ(C)  =  0  &  OFFERING-OBJ(C)  =  A) 
<=>  in(A,  image (Q,  0)); 
fa  ((Q:  OFFERING),  (0:  QUARTER),  A:  COURSE) 

(ex  (C:  OFFERING-LINK)  in(C,  Q)  &  OFFERING-OBJ(C)  =  A  &  OFFERING-OBJ(C)  =  0) 
<=>  in(0,  image (Q,  A)) 
end-association 


link  TEACHES-LINK  is 
class-sort  TEACHES-LINK 
sort  COURSE,  FACULTY 

operations  ATTR-EQUAL:  TEACHES-LINK,  TEACHES-LINK  ->  BOOLEAN 
attributes 

FACULTY-OBJ:  TEACHES-LINK  ->  FACULTY 

COURSE-OBJ:  TEACHES-LINK  ->  COURSE 
methods  CREATE-TEACHES-LINK :  FACULTY,  COURSE  ->  TEACHES-LINK 
events  NEW-TEACHES-LINK :  FACULTY,  COURSE  ->  TEACHES-LINK 
axioms 

ATTR-EQUAL (Tl,  T2)  <=>(C0URSE-0BJ(T1)  =  COURSE-OBJ (T2) 

4  FACULTY-OBJ (Tl)  =  FACULTY-OBJ (T2) ) ; 

COURSE-OBJ(CREATE-TEACHES-LINK(T,  C,  F))  =  C; 

FACULTY-OBJ (CREATE-TEACHES-LINK (T,  C,  F))  =  F; 

ATTR-EQUAL (NEW-TEACHES-LINK (T,  C,  F) ,  (CREATE-TEACHES-LINK(T,  C,  F))) 
end-link 


association  TEACHES  is 
class-sort  TEACHES 


link-class  TEACHES-LINK 

sort  COURSE-CLASS,  FACULTY-CLASS 

operations 

IMAGE:  TEACHES,  COURSE  ->  FACULTY-CLASS 
IMAGE:  TEACHES,  FACULTY  ->  COURSE-CLASS 
events  NEW-TEACHES:  ->  TEACHES 


axioms 


ATTR-EQUAL (Tl,  T2)  <=>(AVERAGE-SIZE(T1)  =  AVERAGE-SIZE(T2) 

4  TIMES-TAUGHT(Tl)  =  TIMES-TAUGHT(T2) ) ; 

NEW-TEACHES ()  =  EMPTY-SET; 

fa  ((C:  TEACHES),  (T:  COURSE),  A:  FACULTY) 

(ex  (F:  TEACHES-LINK)  in(F,  C)  4  TEACHES-OBJ(F)  =  T  4  TEACHES-OBJ(F)  =  A) 


<=>  in(A,  image (C,  T)); 
fa  ((C:  TEACHES),  (T:  COURSE), 
(ex  (F:  TEACHES-LINK)  in(F, 


A:  FACULTY) 

C)  4  TEACHES-OBJ(F)  =  A  4  TEACHES-OBJ(F)  =  T) 


<=>  in(T,  image(C,  A)) 


end-association 


link  ADVISES-LINK  is 
class-sort  ADVISES-LINK 
sort  FACULTY,  STUDENT 

operations  ATTR-EQUAL:  ADVISES-LINK,  ADVISES-LINK  ->  BOOLEAN 
attributes 

STUDENT-OBJ:  ADVISES-LINK  ->  STUDENT 
FACULTY-OBJ:  ADVISES-LINK  ->  FACULTY 
methods  CREATE- ADVISES-LINK :  STUDENT,  FACULTY  ->  ADVISES-LINK 
events  NEW-ADVISES-LINK:  STUDENT,  FACULTY  ->  ADVISES-LINK 


G-23 


eixioms 

ATTR-EQUAL(A1.  A2)  <=>  (FACULTY-OBJ(Al)  =  F ACUITY- DBJ(A2) 

&  STUDEKT-OBJ(Al)  =  STODENT-OBJ(A2)) ; 
FACULTY-OBJ (CREATE- ADVISES-LINK (A,  F,  S))  =  F; 
STUDENT-OBJ(CREATE-ADVISES-LINK(A,  F.  S))  =  S; 

ATTR-EQUAL(NEW-ADVISES-LINK(A,  F,  S) ,  (CREATE- ADVISES-LINK(A,  F,  S))) 
end-link 


association  ADVISES  is 
class-sort  ADVISES 
link-class  ADVISES-LINK 
sort  FACULTY-CLASS,  STUDENT-CLASS 
operations 

IMAGE:  ADVISES.  FACULTY  ->  STUDENT-CLASS 
IMAGE:  ADVISES,  STUDENT  ->  FACULTY-CLASS 
events  NEW-ADVISES:  ->  ADVISES 
axioms 

NEW-ADVISES 0  =  EMPTY-SET; 

fa  ((F:  ADVISES).  (A:  FACULTY),  B:  STUDENT) 

(ex  (S:  ADVISES-LINK)  in(S,  F)  &  ADVISES-OBJ(S)  =  A  &  ADVISES-QBJ(S)  =  B) 
<=>  in(B,  image (F,  A)); 
fa  ((F:  ADVISES),  (A:  FACULTY),  B:  STUDENT) 

(ex  (S:  ADVISES-LINK)  in(S,  F)  &  ADVISES-OBJ(S)  =  B  &  ADVISES-OBJ(S)  =  A) 
<=>  in(A,  image (F,  B)) 
end-association 


link  MEMBER-OF-LINK  is 
class-sort  MEMBER-OF-LINK 
sort  STUDENT,  A-CLASS 

operations  ATTR-EQUAL:  MEMBER-OF-LINK,  MEMBER-OF-LINK  ->  BOOLEAN 
attributes 

A-CLASS-OBJ:  MEMBER-OF-LINK  ->  A-CLASS 

STUDENT-OBJ:  MEMBER-OF-LINK  ->  STUDENT 
methods  CREATE-MEMBER-OF-LINK :  A-CLASS,  STUDENT  ->  MEMBER-OF-LINK 
events  NEW-MEMBER-OF-LINK :  A-CLASS,  STUDENT  ->  MEMBER-OF-LINK 
aixioms 

ATTR-EQUAL (Ml,  M2)  <=>  (STUDENT-OBJ(Ml)  =  STUDENT-OBJ (M2) 

&  A-CLASS-OBJ (Ml)  =  A-CLASS-OBJ (M2) ) ; 

STUDENT-OBJ(CREATE-MEMBER-OF-LINK(M,  S,  A))  =  S; 

A-CLASS-OBJ(CREATE-MEMBER-OF-LINK(M,  S,  A))  =  A; 

ATTR-EQUAL (NEW-MEMBER-OF-LINK (M,  S,  A),  (CREATE-MEMBER-OF-LINK (M,  S,  A))) 
end-link 


association  MEMBER-OF  is 
class-sort  MEMBER-OF 
link-class  MEMBER-OF-LINK 
sort  STUDENT-CLASS,  A-CLASS-CLASS 
operations 

IMAGE:  MEMBER-OF,  STUDENT  ->  A-CLASS-CLASS 

IMAGE:  MEMBER-OF,  A-CLASS  ->  STUDENT-CLASS 
events  NEW-MEMBER-OF :  ->  MEMBER-OF 
axioms 

NEW-MEMBER-OF 0  =  EMPTY-SET; 
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fa  ((M:  MEMBER-OF),  S:  STUDENT)  SIZE(IMAGE(M,  S))  =  1; 
fa  ((S:  MEMBER-OF),  (M:  STUDENT),  B:  A-CLASS) 

(ex  (A:  MEMBER-OF-LINK)  in(A,  S)  Sc  MEMBER-OF-DBJ(A)  =  M  &  MEMBER-OF-OBJ(A)  =  B) 
<=>  in(B,  image(S,  M)); 
fa  ((S:  MEMBER-OF),  (M:  STUDENT),  B:  A-CLASS) 

(ex  (A:  MEMBER-OF-LINK)  in(A,  S)  ft  MEMBER-OF-OBJ(A)  =  B  ft  MEMBER-OF-OBJ(A)  =  M) 
<=>  in(M,  image(S,  B)) 
end-association 


aggregate  DOMAIN-THEORY-AGGREGATE  is 

nodes  FACULTY-WORKLOAD-AGGREGATE ,  FACULTY-WORKLOAD-CLASS,  FACULTY-WORKLOAD 
arcs  FACULTY-WORKLOAD-AGGREGATE  ->  FACULTY-WORKLOAD:  ■[}, 

FACULTY-WORKLOAD  ->  FACULTY-WORKLOAD-CLASS:  {} 
end-aggregate 
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